Expanded on from this earlier draft: https://x.com/VitalikButerin/status/1919263869308191017

The three "stages" of Ethereum rollup security can be described interms of when a security council is allowed to overridetrustless (ie. pure cryptographic or game-theoretic)components:

• Stage 0: security council has full control. Theremay be a proof system (optimistic or ZK) running, but a security councilcan overturn it with a simple majority vote. Hence, the proof system is"advisory only".
• Stage 1: security council can override with 75% (at least6-of-8) approval. A quorum-blocking subset (ie. >= 3) mustbe outside the primary organization. Hence, there is a high, but notimpassable, barrier to overriding the proof system.
• Stage 2: security council can only act in case of provablebugs. Provable bugs could be eg. two redundant proof systems(eg. OP and ZK) disagreeing with each other. And if there are provablebugs, it can only choose between one of the proposed answers: it cannotanswer arbitrarily.

We can model this with a chart showing "what share of the vote" thesecurity council has at each stage:

One important question to ask is: when is it optimal for anL2 to move from stage 0 to stage 1, and from stage 1 to stage2?

The only valid reason to not go to stage 2 immediately is that you donot fully trust the proof system - which is an understandable fear: it'sa lot of code, and if the code if broken, then an attacker couldpotentially steal all of the users' assets. The more confidence you havein your proof system (or, conversely, the less confidence you havein security councils), the more you want to move towards theright.

It turns out that we can quantify this with a simplified mathematicalmodel. First, let's list the assumptions:

• Each security council member has an independent 10% chance of"breaking"
• We treat liveness failure [refusal to sign or keys inaccessible] andsafety failure [signing a wrong thing or keys hacked] as equally likely.In fact, we just assume a single category of "broken" where a "broken"security council member both signs the wrong thing and fails to sign theright thing
• In stage 0, the security council is 4-of-7, in stage 1 it's is6-of-8.
• We assume a single monolithic proof system (as opposed to a 2-of-3design where the security council could break ties if the two disagree).Hence, in stage 2 the security council does not matter at all.

Given these assumptions, and given a particular probabilityof the proof system breaking, we want to minimize the probability of theL2 breaking.

We can do this with binomialdistributions:

• If each security council member has an independent 10% chance ofbreaking, then the chance that at least 4 of 7 will break is \(\sum_{i=4}^7 {7 \choose i} * 0.1^i * 0.9^{7-i} =0.002728\) Thus, a stage 0 rollup has a fixed 0.2728% chance offailing.
• A stage 1 rollup can fail if either the proof system fails and thesecurity council gets >= 3 failures so it can't override (probability\(\sum_{i=3}^8 {8 \choose i} * 0.1^i *0.9^{8-i} = 0.03809179\) multiplied by the proof system failurerate), or if the security council gets 6+ failures and can force anincorrect answer by itself (fixed \(\sum_{i=6}^8 {8 \choose i} * 0.1^i * 0.9^{8-i} =0.00002341\) probability)
• The chance that a stage 2 rollup will break is just equal to theprobability that the proof system fails

Here it is in graph form:

As conjectured, as proof system quality increases, the optimal stageshifts from stage 0 to stage 1, then stage 1 to stage 2. Doing stage 2with a stage-0-quality proof system is worst of all.

Now, note that the assumptions in the above simplified modelare very imperfect:

• In reality, security council members are notindependent, and have "commonmode failures": they could collude, or all get coerced or hacked thesame way, etc. The requirement to have a quorum-blocking subset outsidethe primary organization is meant to mitigate this, but it is still farfrom perfect.
• The proof system could itself be a combination of multipleindependent systems (this is what I advocate in https://ethereum-magicians.org/t/a-simple-l2-security-and-finalization-roadmap/23309...). In this case, (i) the probability of a proof system breaking couldend up very low, and (ii) even in stage 2, security councils matter, asa matter of tiebreaking.

These two arguments both imply stage 1 and stage 2 are both even moreattractive than the chart shows. If you take the math seriously,stage 0 is pretty much never justified: you should launch at leaststraight into stage 1. The main argument that I hear againstis: if a critical bug happens, it may be too hard to get 6 of 8 securitycouncil members to sign fast enough to fix it. But there is an easy wayaround this: give any single security council member the permission todelay withdrawals by 1 or 2 weeks, giving everyone else enough time toact.

At the same time, however, it is a mistake to jump to stage 2too quickly, especially if work to move to stage 2 happens atthe expense of work to harden the underlying proof system.Ideally, data providers like l2beat should show proofsystem audits and maturity metrics (ideally of the proof systemimplementation, not the rollup as a whole, so we can reuse) along withthe stage.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。