add stage description

BEPs/BEP-431.md

@@ -14,7 +14,7 @@ This proposal introduces a Zero Knowledge (ZK) fault proof system for opBNB, uti
 
 ## 2. Abstract
 
-The current fault proof system for Optimism-based chains like opBNB involves a complex, time-consuming, and potentially expensive process. This proposal outlines a ZK-based approach that significantly improves upon the existing system. By using custom circuits for block execution and derivation, along with a specialized fault proof circuit, this system can reduce the challenge period from 7 days to approximately 12 hours while also minimizing gas costs and mitigating censorship risks.
+The current fault proof system for Optimism-based chains like opBNB involves a complex, time-consuming, and potentially expensive process. This proposal outlines a ZK-based approach that significantly improves upon the existing system. By using custom circuits for block execution and derivation, along with a specialized fault proof circuit, this system can reduce the challenge period from several days to approximately 12 hours while also minimizing gas costs and mitigating censorship risks.
 
 ## 3. Status
 
@@ -36,7 +36,7 @@ Additionally, implementing a ZK fault proof system is a crucial step towards ach
 
 ### 5.1 Background
 
-In the last year, Optimism initiated a Foundation Mission Request to develop the Op Stack Zero Knowledge Proof (ZKP) for verifying the correctness of its fault proof program. This initiative aims to reduce the challenge period for Optimism from 7 days to 12 hours and avoid complicated interactive challenge procedures.
+In the last year, Optimism initiated a Foundation Mission Request to develop the Op Stack Zero Knowledge Proof (ZKP) for verifying the correctness of its fault proof program. This initiative aims to reduce the challenge period for Optimism from several days to approximately 12 hours and avoid complicated interactive challenge procedures.
 
 ![ZK Fault Proof for opBNB Approaches](./assets/BEP-431/zk-fault-proof-opbnb-approach.jpg)
 
@@ -71,7 +71,7 @@ The existing Optimism fault proof system consists of two main components:
 
 ### 5.3 Architecture of ZK Fault Proof
 
-![ZK Fault Proof for opBNB Architecture](./assets/BEP-431/zk-fault-proof-opbnb-architecture.png)
+![ZK Fault Proof for opBNB Architecture](./assets/BEP-431/zk-fault-proof-opbnb-architecture.jpg)
 
 The ZK Fault Proof system for opBNB consists of the following key components:
 
@@ -85,7 +85,7 @@ The ZK Fault Proof system for opBNB consists of the following key components:
 
 ### 5.4 System Workflow
 
-![ZK Fault Proof for opBNB Workflow](./assets/BEP-431/zk-fault-proof-opbnb-process.png)
+![ZK Fault Proof for opBNB Workflow](./assets/BEP-431/zk-fault-proof-opbnb-workflow.png)
 
 1. The challenger monitors the L2 output root proposed on-chain by the proposer.
 2. Upon finding an invalid output root, the challenger generates a ZK fault proof for the disputed L1 block.
@@ -151,6 +151,56 @@ The challenger:
 2. Third-party audits of the entire system, including circuits, contracts, and off-chain components.
 3. Phased implementation, starting with a limited scope and gradually expanding responsibilities.
 
+### 5.11 Towards Stage 2 Rollup
+
+The implementation of the ZK Fault Proof System is a significant step towards achieving Stage 2 rollup status for opBNB. Let's review the [stages](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) as defined by L2Beat and assess opBNB's current status and path forward.
+
+#### L2Beat Rollup Stages
+
+- Stage 0 - Full Training Wheels
+  - The project calls itself a rollup.
+  - L2 state roots are posted on L1.
+  - The project provides Data Availability (DA) on L1.
+  - Software capable of reconstructing the rollup's state source is available.
+- Stage 1 - Limited Training Wheels
+  - The project uses a proper proof system.
+  - There are at least 5 external actors that can submit a fraud proof.
+  - Users can exit without the operator's coordination.
+  - Users have at least 7 days to exit in case of unwanted upgrades (Security Council and governance excluded).
+  - The Security Council is properly set up.
+- Stage 2 - No Training Wheels
+  - The fraud proof system is permissionless.
+  - Users have at least 30 days to exit in case of unwanted upgrades.
+  - The Security Council is restricted to act only due to errors detected on chain.
+
+#### Current Status of opBNB
+
+opBNB is currently at **Stage 0**, with the following characteristics:
+- Operated by a centralized sequencer.
+- Uses an optimistic rollup model with a 7-day challenge period.
+- Has a Security Council(admin, whitelisted challengers) with significant powers over the network.
+- Source-available software for state reconstruction from L1 data.
+
+#### What opBNB Needs for Stage 1 and Stage 2
+
+1. Stage 1
+    a. The project uses a proper proof system.
+    b. There are at least 5 external actors that can submit a fraud proof.
+    c. Users have at least 7 days to exit in case of unwanted upgrades (Security Council and governance excluded).
+2. Stage 2
+    a. The fraud proof system is permissionless.
+    b. Users have at least 30 days to exit in case of unwanted upgrades.
+    c. The Security Council is restricted to act only due to errors detected on chain.
+
+
+#### How ZK Fault Proof System Helps and associated actions
+
+- As a fraud proof mechanism, the ZK Fault Proof System enables any participant to submit proofs and contest invalid state transitions. We plan to gradually extend the ability to submit fraud proofs to external parties following the system's implementation. This process will begin with whitelisted community members and eventually open up to all users, addressing points 1.a, 1.b, and 2.a mentioned earlier.
+- The ZK Fault Proof System's implementation will include a pre-submitted op-geth image on L1, representing opBNB's execution logic. We propose introducing a time-delay mechanism for image upgrades (e.g., 7 or 30 days). This approach allows users who disagree with a new version to withdraw their deposits before the upgrade takes effect, satisfying requirements 1.c and 2.b.
+- These modifications will allow us to significantly reduce the operator's administrative powers and limit the Security Council's authority to addressing on-chain errors only. This change fulfills requirement 2.c.
+
+By implementing the ZK Fault Proof System and executing these additional actions, opBNB will make substantial progress towards achieving Stage 2 rollup status. This advancement will significantly enhance the network's security, decentralization, and overall user experience. The process involves a gradual transition through Stage 1, systematically removing the "training wheels" to ultimately reach the fully decentralized and secure Stage 2 status.
+
 ## 6. Rationale
 
 The custom circuit approach offers superior performance compared to generic VM solutions, providing: