A critical bug was found in the implementation of Views in the protocol PtHangzH, which is currently in the exploration phase of the governance procedure. We have prepared a patch for the protocol.
If the protocol is rejected, either by failing to meet the quorum or the supermajority, we intend to submit a patched version in the next voting period.
If the protocol is voted as is, Nomadic Labs will configure the next Octez distribution to automatically patch the bug through the User Activated Protocol Override mechanism. We at Marigold recommend using that distribution as soon as it is available.
Details about the bug
In the Michelson interpreter, calling a view changes key constants in the caller’s environment, but does not restore them correctly. As a result, instructions such as SELF, SENDER and SOURCE will give incorrect results . Consequently, the instructions following a call to the view do not have the right semantic, and could, for example, originate operations that appear to have been sent from the contract providing the view.
By seing such an error at this point, makes me think we should vote no on promotion or is the work around acceptable. What is the impact if not all balers update to the new version of octez, this work around would not be uniformly functionnal?
Especially for a critical bug, it would be best that this is brought up to validators that have not voted yet and communicate a course of action swiftly.
Perhaps, in the interest of time, it would be good for you guys to pick one of the options and then communicate the recommended voting direction to the rest of the non-voting validators.
What do you suggest? stakefish has not yet voted here and we would look to your recommendation.
Why would you vote no? We vote for a feature, not the code! Or do you want a new governance process for every bug that is found in the future? If there will be a bug in Florence will you vote again on the Florence proposal?
However you do bring up a very valid point. Clearly there was not robust enough checks on the Views that had the issue which caused this.
We need stricter standards to not let these slip through again. Especially for significant protocol upgrades, we need better audits. Community (and Validators by proxy) should demand it.
@gorfl do you operate your own infra? Or do you stake with a Tezos Validator? I think your voice and opinion should definitely be made known to the Validator you delegate your tezos to and ask them to act accordingly. I think your passion and opinion would be important a la delegator<>Validator conversations
What follows is my point of view, not necessarily representative of everyone at Marigold
What do you suggest?
I believe the Protocol Override is best, because I expect bakers to vote on features rather than a particular implementation.
Clearly there was not robust enough checks on the Views that had the issue which caused this.
This is not clear at all. Unfortunately, checking for robustness is not trivial. If anyone has any specific idea, I’d gladly discuss it with them in private.
From my point of view, the best thing to do is to hire more core devs across teams and train them to cover for blindspots.
