Hey Vincenzo, overall this seems like a good update to the framework. The removal of “accessibility” makes sense since only Ethereum itself could be green. Distinguishing between the DA Layer and Bridge mostly makes sense but I have some concerns.
I have a few questions on the following sections.
Economic Security
- Indirect Economic Security through Reputational Risk: If there is no direct economic security in the form of a stake, but the bribery risk is publicly verifiable off-chain (i.e., based on the reputational risk of well-known entities). There are a minimum of 5 external actors as part of the committee.
Is there a threshold for what constitutes an entity with enough reputation to have meaningful reputational risk if they cheat? This seems hard to define.
Committee security
Green
- Robust and Diverse Committee: The committee requires that the minimum proportion of honest members (or the network stake) necessary to safely attest to the availability of the data does not exceed 1/3. Entering the operators set is permissionless, subject only to stake requirements and an honest majority of committee members (or a decentralized governance process).
Yellow
- Limited Committee Security: The committee requires the minimum proportion of honest members to not exceed 1/3, with a minimum of 5 external actors. The entering or exiting of committee members from the active operators set can be triggered or vetoed by a centralized entity.
I understand the 1/3 threshold, but perhaps there should be some other metric that relates to committee size e.g. the number of committee members that would have to collude to attest to unavailable data. In other words, the minimum number of committee members required to reach 2/3 + 1 voting power. Otherwise a 5/7 multisig would be treated the same as a validator set of 100 with even stake distribution. Or am I missing something?
It also seems that this item does not care if the Bridge committee is not the same as the DA layer committee. Isn’t it important they are the same committee? Otherwise the economic security and fraud detection mechanism of the DA layer are irrelevant to the security of the bridge.
Upgradability
- Secure Upgradeability: The bridge should have at least a 30-day delay on upgrades, including upgrades initiated by a DAO. Upgrades from a Security Council should be limited to onchain provable bugs.
What defines a DAO in this framework and why is it important that only a DAO can upgrade the bridge as compared to a Security Council if the delay is as long as 30 days?
How do you define “onchain provable bugs”? Does that mean that in order for the security council to trigger the upgrade mechanism they must prove to the bridge that there’s some flaw in the bridge itself? Does such a mechanism exist? I would imagine that most bugs are not provable onchain.
Relayer Failure
- Self-propose: Users can self-propose DA commitments permissionlessly if the centralized relayer fails to do so.
- Governance Rotation: There exists a Security Council or a decentralized governance system able to rotate the permissioned relayer in case of relayer failure or misbehavior. If the system allows a whitelist for relayers, it should comprise at least 5 external actors.
So if relaying is permissionless then this would be green? What about fallback mechanisms that allow the bridge to fallback to Ethereum DA if necessary?