We vote FOR this proposal.
In order to explain our rationale behind this decision, we want to provide some context and considerations from our perspective.
Background:
The Fault Proof proposal was introduced three months ago. The upgrade included one of the most anticipated implementations: real fraud proofs. However, the proposal included two key aspects that raised many questions and doubts about the actual impact and risk of the upgrade: the lack of a complete audit of the system and the conception of the Guardian roles as a consequence.
Amid various concerns and questions, a key comment by Zach was raised regarding the risks introduced by this upgrade; most of them were understood by us within the “reputational risk” category, as the Guardian role was specifically set to minimize any existential risk. For us, our position was to abstain due to the present risk, aligning with the opinion of the DAB leader. We highly value the minimization of reputational risk. Nevertheless, the Collective sent a strong signal in favor of the upgrade.
Granite:
As detailed, bugs were found, which was certainly an expected outcome given the circumstances. Most of the fixes are related to the findings identified in the audit results. In order to move forward, that is, to return to the mode where fault proofs are fully operational, these fixes need to be implemented.
Implementing this upgrade should objectively move us to a safer stage than before, prior to the permissioned mode being triggered. However, it is mentioned how complex Fault Proofs are, so more bugs could still be present. As the safeguards are assumed to be well-audited and managed by the Security Council and Foundation, it should be acceptable to continue having the system as is, even though there are multiple concerns about its design, implementation, and maturity.
Going ahead:
All the discussions across various instances about this upgrade have left us with several points to consider for the Collective:
- Highlight the importance of the Developer Advisory Board in keeping delegates well-informed and, in a sense, making recommendations and outlining expected outcomes for each possible choice. Also, all delegates should ensure that every aspect of protocol upgrade proposals is sufficiently understood before offering support.
- The preference for more conservative measures has been expressed by some members of the Collective that should be taken into account. In a scenario where Audits vs. Shipping, the balance might lean more towards the former.
- Related to point (2), the Collective should revisit the Audit Framework, as the sense of reputational risk could be more highly valued than the current version suggests.
- Expectations on what the Fault Proof roadmap should look like, including the communication of the current constraints and challenges around it and how the system should evolve, regardless of the approach to a multi-proof system.
- The pertinent disclosure of how the running and monitoring of the system actually work, and which nice-to-have features would be appropriate to encourage, for governance’s awareness. This includes any action that could favor the redundancy of the system’s monitoring.