The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two. In this particular case we also reached out for feedback to other L2BEAT team members.
While in general, we highly appreciate both the work that the Security Council did in Season 6 and this retrospective, we have some thoughts and suggestions that might be useful for the upcoming Season.
-
To begin with, we want to address what we think is an important oversight in the Security Council’s mandate.
The SC played a critical role in supporting upgrades aligned with Stage 1 decentralization requirements. The Security Council continued to impact the technical decentralization of Optimism.
We believe specifying who is responsible for reviewing and validating the contents of proposed upgrades might be a good idea. Right now, the responsibility is not clearly assigned as no single entity in governance is specifically accountable for it, and the responsibility simply lies in the Token House in general, which causes it to be diffused. As far as we know, no one is explicitly responsible for validating the contents of proposed upgrades within the Security Council (according to the Internal Operating Procedures) either.
Moreover, the Security Council Charter directly states that:
Council participants are expected to verify that a proposed protocol upgrade or role designation decision has been approved by Optimism Governance. They are not expected to directly evaluate the “merit” of the accompanying proposed code (e.g., for security purposes).
Having security audits for the source code is not solving this issue either as audits, by definition, check if the code works as it is supposed to work; they’re not supposed to be opinionated about whether the code makes changes that are not in the best interest of Optimism Collective.
-
Moreover, the exact calldata of the upgrade that the Security Council is signing is known only to the Security Council, and, as things stand, is not mentioned in the upgrade proposals on the forum or in the vote on Agora. Therefore, only Security Council members can really fact-check if the calldata they are signing is an outcome of a code compilation mentioned in the proposal. In our opinion, the transaction that the Security Council is signing should be mentioned directly in the proposal so that anyone can verify if it’s correct.
-
As far as we know, right now, the participants of the Security Council are required to be individuals using an EOA address. As L2BEAT, we wanted to participate in the Security Council as a multisig, but we were told it’s not possible at this stage. We would like to highly encourage enabling participation as a multisig as this allows for much better operational management and security of this role. With multisig, we could set up our procedures for handling this responsibility, while right now, this responsibility lies solely in the hands of an individual selected from our team.
-
The role of the Security Council in Optimism is not limited to just planned upgrades for the protocol, but also to be a challenger in Optimism’s fault proof system. However, as far as we know, the Security Council fully relies on OP Labs and/or Foundation to serve this role, as individual Security Council participants are not expected to run their own system monitoring tools. The charter says:
It is expected that various members of the Optimism Collective would call attention to a faulty L2 output proposal
So, the Security Council has the final responsibility to intervene in case of a faulty L2 output proposal, but it doesn’t have the tools to fulfill this role as the responsibility for noticing the faulty L2 output proposal is diluted across “various members of the Optimism Collective.” We think this should be addressed and clarified in the future.
-
One more feedback that we got is a small issue - currently the Github repository mixes the contracts that are being verified with the code being executed while verifying/signing. It poses some additional risks related to the maintenance of this code locally. The improvement we’d like to suggest is to separate the contracts and the code that compiles and signs them ) to separate repositories, and try to avoid frequent changes to the non-contracts repositories.
-
Finally, as delegates, we would like to raise the process issue of setting the budget for the Security Council. While we agree that SC should have Budget Autonomy, we are a bit concerned that with the position that the Security Council has within the Optimism ecosystem, the Token House might be simply forced to accept any budget that SC proposes as the situation in which SC does not have any approved budget is an existential threat to the whole ecosystem.