BEP-431: ZK Fault Proof System for opBNB

BEPs/BEP-431.md

@@ -0,0 +1,179 @@
+<pre>
+  BEP: 431
+  Title: ZK Fault Proof System for opBNB
+  Status: Draft
+  Type: Standards
+  Created: 2024-09-05
+</pre>
+
+# BEP-431: ZK Fault Proof System for opBNB
+
+## 1. Summary
+
+This proposal introduces a Zero Knowledge (ZK) fault proof system for opBNB, utilizing a custom circuit approach based on Polygon Zero's type1 zkEVM. The system aims to enhance the security and efficiency of the opBNB network by reducing the challenge period and simplifying the dispute resolution process.
+
+## 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.
+
+## 3. Status
+
+Draft
+
+## 4. Motivation
+
+The current fault proof system for Optimism-based chains has several disadvantages:
+
+1. High gas costs due to multiple on-chain transactions.
+2. Vulnerability to censorship attacks during congested periods.
+3. Long challenge periods, negatively impacting user experience.
+
+A ZK-based fault proof system addresses these issues by requiring only a single on-chain transaction, reducing susceptibility to censorship, and allowing for a significantly shorter challenge period.
+
+Additionally, implementing a ZK fault proof system is a crucial step towards achieving Stage 2 rollup status, as defined by [L2Beat's framework for evaluating rollup maturity](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe).
+
+## 5. Specification
+
+### 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.
+
+![ZK Fault Proof for opBNB Approaches](./assets/BEP-431/zk-fault-proof-opbnb-approach.jpg)
+
+Two main approaches have been considered:
+
+1. **Generic VM Approach**: This involves compiling the fault proof program (written in Go or Rust) into a generic instruction set such as RISCV, WASM, or MIPS. These compiled instructions are then verified for correctness using zkVMs like zkRISCV, zkWASM, or zkMIPS.
+
+2. **Custom Circuit Approach**: This involves developing a custom circuit specifically for the fault proof program, which is expected to offer better performance compared to the generalized VM method.
+
+Our proposal aligns with the custom circuit approach, inspired by Polygon Zero's announcement of a highly performant type1 zkEVM.
+
+### 5.2 Current Fault Proof Overview
+
+The existing Optimism fault proof system consists of two main components:
+
+#### 5.2.1 Offchain Fault Proof Program
+
+1. Derive the disputed block from the anchor L1 block hash.
+2. Execute the disputed block based on the agreed L2 state root and compare the execution result with the claimed output root.
+
+#### 5.2.2 Onchain Fault Dispute Game
+
+1. The attacker and defender take turns initiating on-chain actions based on the claims submitted on-chain by their opponents until they agree on the disputed L2 block.
+2. They repeat the challenge process until they agree on the disputed instruction of the off-chain fault proof program, which uses the disputed L2 block as the input.
+3. Finally, they invoke the on-chain MIPS contract to execute the disputed instruction, which determines the winner.
+
+#### 5.2.3 Disadvantages of the Current System
+
+1. High gas costs due to multiple on-chain transactions from both attacker and defender.
+2. Vulnerability to censorship attacks during network congestion, necessitating long challenge periods for each player to act.
+3. Extended challenge periods (up to 7 days) to mitigate censorship risks, negatively impacting user experience.
+
+### 5.3 Architecture of ZK Fault Proof
+
+![ZK Fault Proof for opBNB Architecture](./assets/BEP-431/zk-fault-proof-opbnb-architecture.png)
+
+The ZK Fault Proof system for opBNB consists of the following key components:
+
+1. **Optimism Block Execution Circuit**: Processes L2 blocks according to the Optimism state transition protocol and generates an execution proof to verify the correctness of the L2 block.
+
+2. **Optimism Block Derivation Circuit**: Encodes the Optimism block derivation logic from an L1 block hash and produces a derivation proof to verify the correctness of the derived L2 block.
+
+3. **Fault Proof Circuit**: Encodes the ZKP verification logic to validate both the execution proof and derivation proof, and includes the consistency check logic between the public inputs of the circuits.
+
+4. **zkFaultProofVerifier Contract**: This contract resides on the L1 chain and is used to verify the correctness of the ZK fault proof, determining which party wins.
+
+### 5.4 System Workflow
+
+![ZK Fault Proof for opBNB Workflow](./assets/BEP-431/zk-fault-proof-opbnb-process.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.
+3. The challenger submits the proof to the zkFaultProofVerifier contract.
+4. If verification passes, the challenger wins the dispute.
+
+### 5.5 Detailed Process
+
+1. **L1 Block Processing**: Extract data from L1 blocks.
+2. **Block Derivation**: Derive L2 blocks from L1 data.
+3. **L2 Block Execution**: Process transactions and state changes.
+4. **Proof Generation**: Create ZK proofs for derivation and execution.
+5. **Fault Proof Circuit**: Combine proofs into a comprehensive fault proof.
+6. **On-chain Verification**: Verify the proof using the zkFaultProofVerifier contract.
+
+### 5.6 Circuit Design
+
+#### 5.6.1 Block Execution Circuit
+
+- Transaction Processing: Executes individual transactions within the block.
+- State Updates: Manages changes to the L2 state resulting from transaction execution.
+- Gas Accounting: Tracks gas usage for each transaction and the block as a whole.
+- Receipt Generation: Creates transaction receipts containing execution results.
+
+#### 5.6.2 Block Derivation Circuit
+
+- L1 Data Parsing: Extracts relevant information from L1 blocks.
+- L2 Block Construction: Assembles L2 blocks based on the parsed L1 data.
+- Sequencing Rules Implementation: Implements the rules for ordering transactions within L2 blocks.
+
+#### 5.6.3 Fault Proof Circuit
+
+- Proof Verification: Checks the validity of both execution and derivation proofs.
+- Consistency Checks: Ensures that the inputs and outputs of the execution and derivation circuits are consistent.
+- Final Proof Generation: Produces a single, comprehensive proof of the entire L2 block processing.
+
+### 5.7 On-chain Verifier Contract
+
+The zkFaultProofVerifier contract:
+
+1. Verifies ZK proofs submitted by challengers.
+2. Determines the outcome of challenges.
+3. Updates the L2 state on L1 if a challenge is successful.
+
+### 5.8 Challenger Implementation
+
+The challenger:
+
+1. Monitors L2 output roots proposed on L1.
+2. Detects inconsistencies between proposed and calculated L2 states.
+3. Generates ZK fault proofs for detected inconsistencies.
+4. Submits challenges to the on-chain verifier contract.
+
+### 5.9 Performance Optimizations
+
+1. Parallel Proof Generation: Implement techniques to generate proofs for multiple transactions or blocks in parallel.
+2. Incremental Proving: Develop methods to update proofs incrementally as new transactions are processed.
+3. Proof Aggregation: Explore techniques to combine multiple proofs into a single, more compact proof.
+
+### 5.10 Security Measures
+
+1. Formal Verification of circuits and contracts.
+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.
+
+## 6. Rationale
+
+The custom circuit approach offers superior performance compared to generic VM solutions, providing:
+
+1. Faster proof generation: 5-6 times faster than generic VM approaches.
+2. Lower computational costs: Generates 10 times fewer ZK cycles for the same batch.
+3. Improved scalability: More efficient proof generation allows for handling larger transaction volumes.
+4. Reduced challenge period: From 7 days to approximately 12 hours.
+5. Minimized gas costs: Requires only a single on-chain transaction for dispute resolution.
+
+## 7. Backwards Compatibility
+
+This proposal requires updates to the opBNB node software and deployment of new verification contracts. Existing transactions and smart contracts are unaffected.
+
+## 8. Security Considerations
+
+1. Thorough auditing and testing of custom circuits and verification contracts.
+2. Special attention to the correctness of block execution, derivation, and fault proof circuits.
+3. Implementation of additional security measures to meet Stage 2 rollup requirements, including:
+   - Extended exit windows for users (e.g., 30-day exit period).
+   - Limitations on Security Council powers.
+   - Fully permissionless validation system.
+
+## 9. License
+
+The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

README.md

@@ -79,6 +79,7 @@ Here is the list of subjects of BEPs:
 | [BEP-404](./BEPs/BEP-404.md) | Clear Miner History when Switching Validator Set          | Standards | Candidate |
 | [BEP-410](./BEPs/BEP-410.md) | Add Agent for Validators          | Standards | Draft     |
 | [BEP-414](./BEPs/BEP-414.md) | EOA based Paymaster API Spec       | Standards | Draft     |
+| [BEP-431](./BEPs/BEP-431.md) | ZK Fault Proof System for opBNB    | Standards | Draft     |
 
 
 
@@ -90,3 +91,4 @@ Here is the list of subjects of BEPs:
 
 # How To Contribute A BEP
 If you have an idea and want to make it a BEP, you may refer [BEP-1](BEP1.md)
+