The OP Contracts Manager is a proxied contract deployed at 0xTODO. It can be deployed as follows:
0xTODO
TODO.
Version 1.0.0 of the OP Contracts Manager deploys the [op-contracts/v1.6.0] +
op-contracts/v1.6.0
Version 1.0.0 of the OP Contracts Manager deploys the op-contracts/v1.6.0 contracts release.
Proxy.sol
The OP Contracts Manager is a proxied contract using the standard Proxy.sol contract that lives in diff --git a/fault-proof/cannon-fault-proof-vm.html b/fault-proof/cannon-fault-proof-vm.html index 1e509924a..915212478 100644 --- a/fault-proof/cannon-fault-proof-vm.html +++ b/fault-proof/cannon-fault-proof-vm.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/fault-proof/index.html b/fault-proof/index.html index 4fa33f3e4..42123114d 100644 --- a/fault-proof/index.html +++ b/fault-proof/index.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/fault-proof/stage-one/bond-incentives.html b/fault-proof/stage-one/bond-incentives.html index a11698a72..1a04ef274 100644 --- a/fault-proof/stage-one/bond-incentives.html +++ b/fault-proof/stage-one/bond-incentives.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/fault-proof/stage-one/bridge-integration.html b/fault-proof/stage-one/bridge-integration.html index 3d1152bc7..935c8af43 100644 --- a/fault-proof/stage-one/bridge-integration.html +++ b/fault-proof/stage-one/bridge-integration.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/fault-proof/stage-one/dispute-game-interface.html b/fault-proof/stage-one/dispute-game-interface.html index bc58a40ae..4bea3b07f 100644 --- a/fault-proof/stage-one/dispute-game-interface.html +++ b/fault-proof/stage-one/dispute-game-interface.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/fault-proof/stage-one/fault-dispute-game.html b/fault-proof/stage-one/fault-dispute-game.html index b1cf1cafe..da23ff18d 100644 --- a/fault-proof/stage-one/fault-dispute-game.html +++ b/fault-proof/stage-one/fault-dispute-game.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/fault-proof/stage-one/honest-challenger-fdg.html b/fault-proof/stage-one/honest-challenger-fdg.html index 14ceae757..9fab2aec0 100644 --- a/fault-proof/stage-one/honest-challenger-fdg.html +++ b/fault-proof/stage-one/honest-challenger-fdg.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/fault-proof/stage-one/index.html b/fault-proof/stage-one/index.html index 08c483116..d66c52a0d 100644 --- a/fault-proof/stage-one/index.html +++ b/fault-proof/stage-one/index.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/glossary.html b/glossary.html index e21b3cecf..54c980b8a 100644 --- a/glossary.html +++ b/glossary.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/governance/gov-token.html b/governance/gov-token.html index fbcbac833..adee8fba4 100644 --- a/governance/gov-token.html +++ b/governance/gov-token.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -281,7 +281,7 @@ Basic Deleg - + @@ -295,7 +295,7 @@ Basic Deleg - + diff --git a/index.html b/index.html index 20d712d67..bd978d50b 100644 --- a/index.html +++ b/index.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/dependency-set.html b/interop/dependency-set.html index 050c47e79..0b709e1fe 100644 --- a/interop/dependency-set.html +++ b/interop/dependency-set.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/derivation.html b/interop/derivation.html index a576f1b80..ffd1ff0bf 100644 --- a/interop/derivation.html +++ b/interop/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/fault-proof.html b/interop/fault-proof.html index 14a4d83f8..1e2894fc9 100644 --- a/interop/fault-proof.html +++ b/interop/fault-proof.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/messaging.html b/interop/messaging.html index 2e85a90d2..4ae8c4b45 100644 --- a/interop/messaging.html +++ b/interop/messaging.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/overview.html b/interop/overview.html index 3248260a4..31efd1900 100644 --- a/interop/overview.html +++ b/interop/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/predeploys.html b/interop/predeploys.html index 07a37ab8f..d5f1ff803 100644 --- a/interop/predeploys.html +++ b/interop/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/rollup-node-p2p.html b/interop/rollup-node-p2p.html index ace052a34..d67b37457 100644 --- a/interop/rollup-node-p2p.html +++ b/interop/rollup-node-p2p.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/sequencer.html b/interop/sequencer.html index ec5bc2830..53f3fd97b 100644 --- a/interop/sequencer.html +++ b/interop/sequencer.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/superchain-weth.html b/interop/superchain-weth.html index 6b945b7b3..a6181ebb2 100644 --- a/interop/superchain-weth.html +++ b/interop/superchain-weth.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/token-bridging.html b/interop/token-bridging.html index 34ca895cf..2c7ee9310 100644 --- a/interop/token-bridging.html +++ b/interop/token-bridging.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/tx-pool.html b/interop/tx-pool.html index f342dc087..9af4962d1 100644 --- a/interop/tx-pool.html +++ b/interop/tx-pool.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/upgrade.html b/interop/upgrade.html index 2e14a9722..e23a128f5 100644 --- a/interop/upgrade.html +++ b/interop/upgrade.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/interop/verifier.html b/interop/verifier.html index 21c8b898e..1347154c4 100644 --- a/interop/verifier.html +++ b/interop/verifier.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/print.html b/print.html index 46cb2825f..e48a737a9 100644 --- a/print.html +++ b/print.html @@ -98,7 +98,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -8697,10 +8697,9 @@ Smart Contracts -This document is not finalized and should be considered experimental. Execution Layer -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters Consensus Layer @@ -8708,8 +8707,7 @@ Consensus Smart Contracts -Predeploys -Configurability +System Config Holocene L2 Chain Derivation Changes @@ -9024,81 +9022,36 @@ L Table of Contents +Overview Timestamp Activation -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters -Header Validity Rules -Header Withdrawals Root - -Rationale -Forwards Compatibility Considerations -Client Implementation Considerations - - - - Extended PayloadAttributesV3 eip1559Params encoding -Execution -Rationale +Execution +Rationale eip1559Params in Header -Header Validity Rules +Header Validity Rules Encoding -Rationale +Rationale + + +Overview +The EIP-1559 parameters are encoded in the block header's nonce field and can be +configured dynamically through the SystemConfig. Timestamp Activation Holocene, like other network upgrades, is activated at a timestamp. Changes to the L2 Block execution rules are applied when the L2 Timestamp >= activation time. -L2ToL1MessagePasser Storage Root in Header -After Holocene's activation, the L2 block header's withdrawalsRoot field will consist of the 32-byte -L2ToL1MessagePasser account storage root after the block has been executed, and after the -insertions and deletions have been applied to the trie. In other words, the storage root should be the same root -that is returned by eth_getProof at the given block number. -Header Validity Rules -Prior to holocene activation, the L2 block header's withdrawalsRoot field must be: - -nil if Canyon has not been activated. -keccak256(rlp(empty_string_code)) if Canyon has been activated. - -After Holocene activation, an L2 block header's withdrawalsRoot field is valid iff: - -It is exactly 32 bytes in length. -The L2ToL1MessagePasser account storage root, as committed to in the storageRoot within the block -header, is equal to the header's withdrawalsRoot field. - -Header Withdrawals Root -Byte offsetDescription -[0, 32)L2ToL1MessagePasser account storage root - - -Rationale -Currently, to generate L2 output roots for historical blocks, an archival node is required. This directly -places a burden on users of the system in a post-fault-proofs world, where: - -A proposer must have an archive node to propose an output root at the safe head. -A user that is proving their withdrawal must have an archive node to verify that the output root they are proving -their withdrawal against is indeed valid and included within the safe chain. - -Placing the L2ToL1MessagePasser account storage root in the withdrawalsRoot field alleviates this burden -for users and protocol participants alike, allowing them to propose and verify other proposals with lower operating costs. -Forwards Compatibility Considerations -As it stands, the withdrawalsRoot field is unused within the OP Stack's header consensus format, and will never be -used for other reasons that are currently planned. Setting this value to the account storage root of the withdrawal -directly fits with the OP Stack, and makes use of the existing field in the L1 header consensus format. -Client Implementation Considerations -Varous EL clients store historical state of accounts differently. If, as a contrived case, an OP Stack chain did not have -an outbound withdrawal for a long period of time, the node may not have access to the account storage root of the -L2ToL1MessagePasser. In this case, the client would be unable to keep consensus. However, most modern -clients are able to at the very least reconstruct the account storage root at a given block on the fly if it does not -directly store this information. -Extended PayloadAttributesV3 +Dynamic EIP-1559 Parameters +Extended PayloadAttributesV3 The PayloadAttributesV3 type is extended to: PayloadAttributesV3: { @@ -9113,7 +9066,7 @@ eip1559Params encoding +eip1559Params encoding NameTypeByte Offset denominatoru32 (big-endian)[0, 4) elasticityu32 (big-endian)[4, 8) @@ -9133,19 +9086,19 @@ Execution -Rationale +Rationale This type is made available in the payload attributes to allow the block builder to dynamically control the EIP-1559 parameters of the chain. As described in the derivation - AttributesBuilder section, the derivation pipeline must populate this field from the SystemConfig during payload building, similar to how it must reference the SystemConfig for the gasLimit field. -eip1559Params in Header +eip1559Params in Header Upon Holocene activation, the L2 block header's nonce field will consist of the 8-byte eip1559Params value. -Header Validity Rules +Header Validity Rules Prior to Holocene activation, the L2 block header's nonce field is valid iff it is equal to u64(0). After Holocene activation, The L2 block header's nonce field is valid iff it is non-zero. -Encoding +Encoding The encoding of the eip1559Params value is described in eip1559Params encoding. -Rationale +Rationale By chosing to put the eip1559Params in the PayloadAttributes rather than in the L1 block info transaction, the EIP-1559 parameters for the chain are not available within history. This would place a burden on performing historical execution, as L1 would have to be consulted for fetching the values from the SystemConfig contract. @@ -9153,251 +9106,27 @@ Rationale purity of the function that computes the next block's base fee from the chain configuration, parent block header, and next block timestamp. -Overview - - -Table of Contents - -Constants -Predeploys - -L1Block - -Storage -Interface - -setHolocene -setConfig -baseFeeVaultConfig -sequencerFeeVaultConfig -l1FeeVaultConfig -l1CrossDomainMessenger -l1StandardBridge -l1ERC721Bridge -remoteChainId - - - - -FeeVault - -Interface - -config - - - - -L2CrossDomainMessenger - -Interface - - -L2ERC721Bridge - -Interface - - -L2StandardBridge - -Interface - - -OptimismMintableERC721Factory - - -Security Considerations - -GovernanceToken - - - - -This upgrade enables a deterministic L2 genesis state by moving all network -specific configuration out of the initial L2 genesis state. All network specific -configuration is sourced from deposit transactions during the initialization -of the SystemConfig. -Constants -NameValueDefinition -ConfigTypeuint8An enum representing the type of config being set -WithdrawalNetworkuint8(0) or uint8(1)0 means withdraw to L1, 1 means withdraw to L2 -RECIPIENTaddressThe account that will receive funds sent out of the FeeVault -MIN_WITHDRAWAL_AMOUNTuint256The minimum amount of native asset held in the FeeVault before withdrawal is authorized -Fee Vault Configbytes32bytes32((WithdrawalNetwork << 248) || uint256(uint88(MIN_WITHDRAWAL_AMOUNT)) || uint256(uint160(RECIPIENT))) -BASE_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.basefeevaultconfig")) - 1)The Fee Vault Config for the BaseFeeVault -L1_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.l1feevaultconfig")) - 1)The Fee Vault Config for the L1FeeVault -SEQUENCER_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.sequencerfeevaultconfig")) - 1)The Fee Vault Config for the SequencerFeeVault -L1_CROSS_DOMAIN_MESSENGER_ADDRESSbytes32(uint256(keccak256("opstack.l1crossdomainmessengeraddress")) - 1)abi.encode(address(L1CrossDomainMessengerProxy)) -L1_ERC_721_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1erc721bridgeaddress")) - 1)abi.encode(address(L1ERC721BridgeProxy)) -L1_STANDARD_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1standardbridgeaddress")) - 1)abi.encode(address(L1StandardBridgeProxy)) -REMOTE_CHAIN_IDbytes32(uint256(keccak256("opstack.remotechainid")) - 1)Chain ID of the remote chain - - -Predeploys -All network specific configuration is moved to a single contract, the L1Block predeploy. -All predeploys make calls to the L1Block contract to fetch network specific configuration -rather than reading it from local state. -graph LR - subgraph L1 - SystemConfig -- "setConfig(uint8,bytes)" --> OptimismPortal - end - subgraph L2 - L1Block - BaseFeeVault -- "baseFeeVaultConfig()(address,uint256,uint8)" --> L1Block - SequencerFeeVault -- "sequencerFeeVaultConfig()(address,uint256,uint8)" --> L1Block - L1FeeVault -- "l1FeeVaultConfig()(address,uint256,uint8)" --> L1Block - L2CrossDomainMessenger -- "l1CrossDomainMessenger()(address)" --> L1Block - L2StandardBridge -- "l1StandardBridge()(address)" --> L1Block - L2ERC721Bridge -- "l1ERC721Bridge()(address)" --> L1Block - OptimismMintableERC721Factory -- "remoteChainId()(uint256)" --> L1Block - end - OptimismPortal -- "setConfig(uint8,bytes)" --> L1Block - -L1Block -Storage -The following storage slots are defined: - -BASE_FEE_VAULT_CONFIG -L1_FEE_VAULT_CONFIG -SEQUENCER_FEE_VAULT_CONFIG -L1_CROSS_DOMAIN_MESSENGER_ADDRESS -L1_ERC_721_BRIDGE_ADDRESS -L1_STANDARD_BRIDGE_ADDRESS -REMOTE_CHAIN_ID - -Each slot MUST have a defined ConfigType that authorizes the setting of the storage slot -via a deposit transaction from the DEPOSITOR_ACCOUNT. -Interface -setHolocene -This function is meant to be called once on the activation block of the holocene network upgrade. -It MUST only be callable by the DEPOSITOR_ACCOUNT once. When it is called, it MUST call -call each getter for the network specific config and set the returndata into storage. -setConfig -This function MUST only be callable by the DEPOSITOR_ACCOUNT. It modifies the storage directly -of the L1Block contract. It MUST handle all defined ConfigTypes. To ensure a simple ABI, the -bytes value MUST be abi decoded based on the ConfigType. -function setConfig(ConfigType,bytes) - -Note that ConfigType is an enum which is an alias for a uint8. -baseFeeVaultConfig -This function MUST be called by the BaseFeeVault to fetch network specific configuration. -function baseFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -sequencerFeeVaultConfig -This function MUST be called by the SequencerFeeVault to fetch network specific configuration. -function sequencerFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1FeeVaultConfig -This function MUST be called by the L1FeeVault to fetch network specific configuration. -function l1FeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1CrossDomainMessenger -This function MUST be called by the L2CrossDomainMessenger to fetch the address of the L1CrossDomainMessenger. -function l1CrossDomainMessenger()(address) - -l1StandardBridge -This function MUST be called by the L2StandardBridge to fetch the address of the L2CrossDomainMessenger. -function l1StandardBridge()(address) - -l1ERC721Bridge -This function MUST be called by the L2ERC721Bridge to fetch the address of the L1ERC721Bridge. -function l1ERC721Bridge()(address) - -remoteChainId -This function MUST be called by the OptimismMintableERC721Factory to fetch the chain id of the remote chain. -For an L2, this is the L1 chain id. -function remoteChainId()(uint256) - -FeeVault -The following changes apply to each of the BaseFeeVault, the L1FeeVault and the SequencerFeeVault. -Interface -The following functions are updated to read from the L1Block contract: - -recipient()(address) -withdrawalNetwork()(WithdrawalNetwork) -minWithdrawalAmount()(uint256) -withdraw() - -NameCall -BaseFeeVaultL1Block.baseFeeVaultConfig() -SequencerFeeVaultL1Block.sequencerFeeVaultConfig() -L1FeeVaultL1Block.l1FeeVaultConfig() - - -config -A new function is added to fetch the full Fee Vault Config. -function config()(address,uint256,WithdrawalNetwork) - -L2CrossDomainMessenger -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1CrossDomainMessenger(): - -otherMessenger()(address) -OTHER_MESSENGER()(address) - -L2ERC721Bridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1ERC721Bridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -L2StandardBridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1StandardBridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -OptimismMintableERC721Factory -The chain id is no longer read from storage but instead is read from the L1Block contract by calling -L1Block.remoteChainId() -Security Considerations -GovernanceToken -The predeploy defined by GovernanceToken should be an empty account until it is defined by -a future hardfork. +Predeploys -Configurability +System Config Table of Contents -Overview -Constants - -ConfigType - - -SystemConfig - -ConfigUpdate -Initialization -Modifying EIP-1559 Parameters -Interface +Overview -EIP-1559 Params +ConfigUpdate +Initialization +Modifying EIP-1559 Parameters +Interface -setEIP1559Params -eip1559Elasticity -eip1559Denominator - - -Fee Vault Config +EIP-1559 Params -setBaseFeeVaultConfig -setL1FeeVaultConfig -setSequencerFeeVaultConfig - - - - +setEIP1559Params +eip1559Elasticity +eip1559Denominator -OptimismPortal - -Interface - -setConfig @@ -9405,23 +9134,7 @@ Configurabili Overview -The SystemConfig and OptimismPortal are updated with a new flow for chain -configurability. -Constants -ConfigType -The ConfigType enum represents configuration that can be modified. -NameValueDescription -SET_GAS_PAYING_TOKENuint8(0)Modifies the gas paying token for the chain -SET_BASE_FEE_VAULT_CONFIGuint8(1)Sets the Fee Vault Config for the BaseFeeVault -SET_L1_FEE_VAULT_CONFIGuint8(2)Sets the Fee Vault Config for the L1FeeVault -SET_SEQUENCER_FEE_VAULT_CONFIGuint8(3)Sets the Fee Vault Config for the SequencerFeeVault -SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESSuint8(4)Sets the L1CrossDomainMessenger address -SET_L1_ERC_721_BRIDGE_ADDRESSuint8(5)Sets the L1ERC721Bridge address -SET_L1_STANDARD_BRIDGE_ADDRESSuint8(6)Sets the L1StandardBridge address -SET_REMOTE_CHAIN_IDuint8(7)Sets the chain id of the base chain - - -SystemConfig +The SystemConfig is updated to allow for dynamic EIP-1559 parameters. ConfigUpdate The following ConfigUpdate event is defined where the CONFIG_VERSION is uint256(0): NameValueDefinitionUsage @@ -9440,21 +9153,12 @@ Initialization< emit ConfigUpdate.GAS_LIMIT emit ConfigUpdate.UNSAFE_BLOCK_SIGNER emit ConfigUpdate.EIP_1559_PARAMS -setConfig(SET_GAS_PAYING_TOKEN) -setConfig(SET_BASE_FEE_VAULT_CONFIG) -setConfig(SET_L1_FEE_VAULT_CONFIG) -setConfig(SET_SEQUENCER_FEE_VAULT_CONFIG) -setConfig(SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESS) -setConfig(SET_L1_ERC_721_BRIDGE_ADDRESS) -setConfig(SET_L1_STANDARD_BRIDGE_ADDRESS) -setConfig(SET_REMOTE_CHAIN_ID) - -These actions MAY only be triggered if there is a diff to the value. + Modifying EIP-1559 Parameters A new SystemConfig UpdateType is introduced that enables the modification of EIP-1559 parameters. This allows for the chain operator to modify the BASE_FEE_MAX_CHANGE_DENOMINATOR and the ELASTICITY_MULTIPLIER. -Interface +Interface EIP-1559 Params setEIP1559Params This function MUST only be callable by the chain governor. @@ -9470,39 +9174,6 @@ e This function returns the currently configured EIP-1559 denominator. function eip1559Denominator()(uint64) -Fee Vault Config -For each FeeVault, there is a setter for its config. The arguments to the setter include -the RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork. -Each of these functions should be public and only callable by the chain governor. -Each function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType. -setBaseFeeVaultConfig -function setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork) - -setL1FeeVaultConfig -function setL1FeeVaultConfig(address,uint256,WithdrawalNetwork) - -setSequencerFeeVaultConfig -function setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork) - -OptimismPortal -The OptimismPortal is updated to emit a special system TransactionDeposited event. -Interface -setConfig -The setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig -is the single source of truth for chain operator ownership. -function setConfig(ConfigType,bytes) - -This function emits a TransactionDeposited event. -event TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData); - -The following fields are included: - -from is the DEPOSITOR_ACCOUNT -to is Predeploys.L1Block -version is uint256(0) -opaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit -is 200_000, isCreation is false and the data is abi.encodeCall(L1Block.setConfig, (_type, _value)) - Governance Token @@ -9670,7 +9341,7 @@ Overview The terms "custom gas token", "gas paying token", "native asset" and "gas paying asset" can all be used interchangeably. Note, Ether is not a custom gas token, but may be used to pay gas. More on this in Configuring the Gas Paying Token. -Constants +Constants ConstantValueDescription ETHER_TOKEN_ADDRESSaddress(0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE)Represents ether for gas paying asset DEPOSITOR_ACCOUNTaddress(0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001)Account with auth permissions on L1Block contract @@ -9766,7 +9437,7 @@ Gas Token Awa L2CrossDomainMessenger OptimismPortal -OptimismPortal +OptimismPortal The OptimismPortal is updated with a new interface specifically for depositing custom tokens. depositERC20Transaction The depositERC20Transaction function is useful for sending custom gas tokens to L2. It is broken out into its @@ -9848,7 +9519,7 @@ Cro The L1CrossDomainMessenger fetches this tuple from the SystemConfig contract. The L2CrossDomainMessenger fetches this tuple from the L1Block contract. -SystemConfig +SystemConfig The SystemConfig is the source of truth for the address of the custom gas token. It does on chain validation, stores information about the token and well as passes the information to L2. initialize @@ -9860,7 +9531,7 @@ initialize symbol MUST be less than or equal to 32 bytes. If the token passes all of these checks, OptimismPortal.setGasPayingToken is called. The implementation of initialize MUST not allow the chain operator to change the address of the custom gas token if it is already set. -L1Block +L1Block The L1Block contract is upgraded with a permissioned function setGasPayingToken that is used to set information about the gas paying token. The DEPOSITOR_ACCOUNT MUST be the only account that can call the setter function. This setter is differentiated from the setL1BlockValues functions because the gas paying @@ -10019,7 +9690,7 @@ Fees blobbasefee. When a custom gas token is used, fees are paid in the custom gas token but the conversion rate to ether is not taken into account as part of the protocol. It is assumed that the fees will be configured by the chain operator such that the revenue earned in custom gas token can be swapped into ether to pay for posting the data to L1. -Security Considerations +Security Considerations OptimismPortal Token Allowance The OptimismPortal makes calls on behalf of users. It is therefore unsafe to be able to call the address of the custom gas token itself from the OptimismPortal because it would be a simple way to approve an attacker's @@ -10287,7 +9958,7 @@ Safet that an L2 block is derived from becomes finalized, the L2 block can be marked as finalized. The engine queue will maintain a longer buffer of L2 blocks waiting for the DA window to expire and the L1 block with the commitment to be finalized in order to signal finality. -Security Considerations +Security Considerations The Data Availability Challenge contract mitigates DoS vulnerability with a payable bond requirement making challenging the availability of a commitment at least as expensive as submitting the data onchain to resolve the challenge. @@ -10387,7 +10058,7 @@ Security Considerations +Security Considerations Layer 1 as Part of the Dependency Set The layer one MAY be part of the dependency set if the fault proof implementation is set up to support it. It is known that it is possible but it is not known if this is going to be @@ -10603,7 +10274,7 @@ Boundin Every block cannot depend on expired messages, as per the Message expiry invariant. The verifier is responsible for filtering out non-canonical parts of the graph. -Security Considerations +Security Considerations Cyclic dependencies If there is a cycle in the dependency set, chains MUST still be able to promote unsafe blocks to safe blocks. A cycle in the dependency set happens anytime that two chains are in each other's @@ -11126,7 +10797,7 @@ Overview The Beacon Contract implements the interface defined in EIP-1967. The implementation address gets deduced similarly to the GasPriceOracle address in Ecotone and Fjord updates. -L1Block +L1Block ConstantValue Address0x4200000000000000000000000000000000000015 DEPOSITOR_ACCOUNT0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 @@ -11253,7 +10924,7 @@ event StandardL2TokenCreated(address indexed remoteToken, address indexed localToken); -L2StandardBridge +L2StandardBridge ConstantValue Address0x4200000000000000000000000000000000000010 @@ -11436,7 +11107,7 @@ Invariants -Security Considerations +Security Considerations TODO Sequencer @@ -11561,7 +11232,7 @@ Sponsorship If a user does not have ether to pay for the gas of an executing message, application layer sponsorship solutions can be created. It is possible to create an MEV incentive by paying tx.origin in the executing message. This can be done by wrapping the L2ToL2CrossDomainMessenger with a pair of relaying contracts. -Security Considerations +Security Considerations Cross Chain Message Latency The latency at which a cross chain message is relayed from the moment at which it was initiated is bottlenecked by the security of the preconfirmations. An initiating transaction and a executing transaction MAY have the same timestamp, @@ -11699,7 +11370,7 @@ Honest Verifi follows. The main difference is that the validity of included executing messages is verified instead of verifying possible executing messages before inclusion. -Security Considerations +Security Considerations Forced Inclusion of Cross Chain Messages The design is particular to not introduce any sort of "forced inclusion" between L2s. This design space introduces risky synchrony assumptions and forces the introduction of a message queue to prevent denial of service attacks where @@ -11739,7 +11410,7 @@ P2P Networking< sets of executing messages to nodes of remote chains so that they know exactly what initiating messages to look for. An optimization on this would involve working with commitments to this data so that less data is sent around via p2p. -Security Considerations +Security Considerations TODO Fault Proof @@ -11761,7 +11432,7 @@ No changes to the dispute game bisection are required. The only changes required are to the fault proof program itself. The insight is that the fault proof program can be a superset of the state transition function. -Security Considerations +Security Considerations TODO Interop Network Upgrade @@ -11839,7 +11510,7 @@ L1 Attributes Deposited Transaction Calldata. -Security Considerations +Security Considerations TODO Token Bridging @@ -11899,7 +11570,7 @@ Properties Notice that ERC20s that do not implement the standard can still be fungible using interop message passing using a custom bridge or implementing sendERC20 and relayERC20 on their own contracts. -Interface +Interface Implementations of the SuperchainERC20 standard will need to implement two external functions and two events: __superchainMint Mints _amount of token to address _account. It should only be callable by the SuperchainERC20Bridge @@ -12098,7 +11769,7 @@ Constants +Constants NameValue SuperchainWETH Address0x4200000000000000000000000000000000000024 ETHLiquidity Address0x4200000000000000000000000000000000000025 @@ -12266,7 +11937,7 @@ Security Considerations +Security Considerations Gas Considerations There must be sufficient gas available in the block to destroy deposit context. There's no guarantee on the minimum gas available for the second L1 attributes transaction as the block @@ -12330,7 +12001,7 @@ Security Considerations +Security Considerations Mempool Denial of Service Since the validation of the executing message relies on a remote RPC request, this introduces a denial of service attack vector. The cost of network access is magnitudes larger than in memory validity checks. @@ -12378,8 +12049,8 @@ OP Deployment The OP Contracts Manager is a proxied contract deployed at 0xTODO. It can be deployed as follows: TODO. -Interface -Version 1.0.0 of the OP Contracts Manager deploys the [op-contracts/v1.6.0] +Interface +Version 1.0.0 of the OP Contracts Manager deploys the op-contracts/v1.6.0 contracts release. Proxy.sol The OP Contracts Manager is a proxied contract using the standard Proxy.sol contract that lives in @@ -12478,7 +12149,7 @@ Con -Security Considerations +Security Considerations Chain ID Source of Truth One of the implicit restrictions on chain ID is that deploy can only be called once per chain ID, because contract addresses are a function of chain ID. However, diff --git a/protocol/batcher.html b/protocol/batcher.html index 3b2dd42f6..b43477961 100644 --- a/protocol/batcher.html +++ b/protocol/batcher.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/bridges.html b/protocol/bridges.html index 82d8153b0..78ccebfed 100644 --- a/protocol/bridges.html +++ b/protocol/bridges.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/canyon/overview.html b/protocol/canyon/overview.html index 6676f930a..60f52a8c2 100644 --- a/protocol/canyon/overview.html +++ b/protocol/canyon/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/configurability.html b/protocol/configurability.html index 79b184b12..8cf628d3c 100644 --- a/protocol/configurability.html +++ b/protocol/configurability.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/delta/overview.html b/protocol/delta/overview.html index a3601d0d5..359a3d161 100644 --- a/protocol/delta/overview.html +++ b/protocol/delta/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/delta/span-batches.html b/protocol/delta/span-batches.html index 3232dddcf..b9de7318b 100644 --- a/protocol/delta/span-batches.html +++ b/protocol/delta/span-batches.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/deposits.html b/protocol/deposits.html index 2e8b7b28a..9edf1b72d 100644 --- a/protocol/deposits.html +++ b/protocol/deposits.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/derivation.html b/protocol/derivation.html index f67e22c5e..b84e7f620 100644 --- a/protocol/derivation.html +++ b/protocol/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/derivation.html b/protocol/ecotone/derivation.html index 69f48b18d..48edf5eae 100644 --- a/protocol/ecotone/derivation.html +++ b/protocol/ecotone/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/l1-attributes.html b/protocol/ecotone/l1-attributes.html index 94c9a9abb..fdba52917 100644 --- a/protocol/ecotone/l1-attributes.html +++ b/protocol/ecotone/l1-attributes.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/overview.html b/protocol/ecotone/overview.html index ffb372c15..d95d00c2b 100644 --- a/protocol/ecotone/overview.html +++ b/protocol/ecotone/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/exec-engine.html b/protocol/exec-engine.html index a994871cc..115393699 100644 --- a/protocol/exec-engine.html +++ b/protocol/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/derivation.html b/protocol/fjord/derivation.html index 344bdbaf3..0a1ae0b01 100644 --- a/protocol/fjord/derivation.html +++ b/protocol/fjord/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/exec-engine.html b/protocol/fjord/exec-engine.html index 01d2281fd..69cb1bc77 100644 --- a/protocol/fjord/exec-engine.html +++ b/protocol/fjord/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/overview.html b/protocol/fjord/overview.html index 783db2fbb..30f1c440c 100644 --- a/protocol/fjord/overview.html +++ b/protocol/fjord/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/predeploys.html b/protocol/fjord/predeploys.html index bae67eae6..d46e6398f 100644 --- a/protocol/fjord/predeploys.html +++ b/protocol/fjord/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/derivation.html b/protocol/granite/derivation.html index e9d88dbae..e19cba517 100644 --- a/protocol/granite/derivation.html +++ b/protocol/granite/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/exec-engine.html b/protocol/granite/exec-engine.html index 8c0f1e46d..684d3fb06 100644 --- a/protocol/granite/exec-engine.html +++ b/protocol/granite/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/overview.html b/protocol/granite/overview.html index 7b5492827..bb2905a4a 100644 --- a/protocol/granite/overview.html +++ b/protocol/granite/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/guaranteed-gas-market.html b/protocol/guaranteed-gas-market.html index c42c12354..863931f80 100644 --- a/protocol/guaranteed-gas-market.html +++ b/protocol/guaranteed-gas-market.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/holocene/derivation.html b/protocol/holocene/derivation.html index f1eea3faf..c38652a86 100644 --- a/protocol/holocene/derivation.html +++ b/protocol/holocene/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/holocene/exec-engine.html b/protocol/holocene/exec-engine.html index d44a82f56..4253e4082 100644 --- a/protocol/holocene/exec-engine.html +++ b/protocol/holocene/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -194,81 +194,36 @@ L2 Ex Table of Contents +Overview Timestamp Activation -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters -Header Validity Rules -Header Withdrawals Root - -Rationale -Forwards Compatibility Considerations -Client Implementation Considerations - - - - Extended PayloadAttributesV3 eip1559Params encoding -Execution -Rationale +Execution +Rationale eip1559Params in Header -Header Validity Rules +Header Validity Rules Encoding -Rationale +Rationale + + +Overview +The EIP-1559 parameters are encoded in the block header's nonce field and can be +configured dynamically through the SystemConfig. Timestamp Activation Holocene, like other network upgrades, is activated at a timestamp. Changes to the L2 Block execution rules are applied when the L2 Timestamp >= activation time. -L2ToL1MessagePasser Storage Root in Header -After Holocene's activation, the L2 block header's withdrawalsRoot field will consist of the 32-byte -L2ToL1MessagePasser account storage root after the block has been executed, and after the -insertions and deletions have been applied to the trie. In other words, the storage root should be the same root -that is returned by eth_getProof at the given block number. -Header Validity Rules -Prior to holocene activation, the L2 block header's withdrawalsRoot field must be: - -nil if Canyon has not been activated. -keccak256(rlp(empty_string_code)) if Canyon has been activated. - -After Holocene activation, an L2 block header's withdrawalsRoot field is valid iff: - -It is exactly 32 bytes in length. -The L2ToL1MessagePasser account storage root, as committed to in the storageRoot within the block -header, is equal to the header's withdrawalsRoot field. - -Header Withdrawals Root -Byte offsetDescription -[0, 32)L2ToL1MessagePasser account storage root - - -Rationale -Currently, to generate L2 output roots for historical blocks, an archival node is required. This directly -places a burden on users of the system in a post-fault-proofs world, where: - -A proposer must have an archive node to propose an output root at the safe head. -A user that is proving their withdrawal must have an archive node to verify that the output root they are proving -their withdrawal against is indeed valid and included within the safe chain. - -Placing the L2ToL1MessagePasser account storage root in the withdrawalsRoot field alleviates this burden -for users and protocol participants alike, allowing them to propose and verify other proposals with lower operating costs. -Forwards Compatibility Considerations -As it stands, the withdrawalsRoot field is unused within the OP Stack's header consensus format, and will never be -used for other reasons that are currently planned. Setting this value to the account storage root of the withdrawal -directly fits with the OP Stack, and makes use of the existing field in the L1 header consensus format. -Client Implementation Considerations -Varous EL clients store historical state of accounts differently. If, as a contrived case, an OP Stack chain did not have -an outbound withdrawal for a long period of time, the node may not have access to the account storage root of the -L2ToL1MessagePasser. In this case, the client would be unable to keep consensus. However, most modern -clients are able to at the very least reconstruct the account storage root at a given block on the fly if it does not -directly store this information. -Extended PayloadAttributesV3 +Dynamic EIP-1559 Parameters +Extended PayloadAttributesV3 The PayloadAttributesV3 type is extended to: PayloadAttributesV3: { @@ -283,7 +238,7 @@ eip1559Params encoding +eip1559Params encoding NameTypeByte Offset denominatoru32 (big-endian)[0, 4) elasticityu32 (big-endian)[4, 8) @@ -303,19 +258,19 @@ Execution -Rationale +Rationale This type is made available in the payload attributes to allow the block builder to dynamically control the EIP-1559 parameters of the chain. As described in the derivation - AttributesBuilder section, the derivation pipeline must populate this field from the SystemConfig during payload building, similar to how it must reference the SystemConfig for the gasLimit field. -eip1559Params in Header +eip1559Params in Header Upon Holocene activation, the L2 block header's nonce field will consist of the 8-byte eip1559Params value. -Header Validity Rules +Header Validity Rules Prior to Holocene activation, the L2 block header's nonce field is valid iff it is equal to u64(0). After Holocene activation, The L2 block header's nonce field is valid iff it is non-zero. -Encoding +Encoding The encoding of the eip1559Params value is described in eip1559Params encoding. -Rationale +Rationale By chosing to put the eip1559Params in the PayloadAttributes rather than in the L1 block info transaction, the EIP-1559 parameters for the chain are not available within history. This would place a burden on performing historical execution, as L1 would have to be consulted for fetching the values from the SystemConfig contract. diff --git a/protocol/holocene/overview.html b/protocol/holocene/overview.html index 0ce159035..1714698a1 100644 --- a/protocol/holocene/overview.html +++ b/protocol/holocene/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -199,10 +199,9 @@ Smart Contracts -This document is not finalized and should be considered experimental. Execution Layer -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters Consensus Layer @@ -210,8 +209,7 @@ Consensus Lay Smart Contracts -Predeploys -Configurability +System Config diff --git a/protocol/holocene/predeploys.html b/protocol/holocene/predeploys.html index 3c4f9c31d..3c6067ec3 100644 --- a/protocol/holocene/predeploys.html +++ b/protocol/holocene/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -189,209 +189,7 @@ OP Stack Specification -Overview - - -Table of Contents - -Constants -Predeploys - -L1Block - -Storage -Interface - -setHolocene -setConfig -baseFeeVaultConfig -sequencerFeeVaultConfig -l1FeeVaultConfig -l1CrossDomainMessenger -l1StandardBridge -l1ERC721Bridge -remoteChainId - - - - -FeeVault - -Interface - -config - - - - -L2CrossDomainMessenger - -Interface - - -L2ERC721Bridge - -Interface - - -L2StandardBridge - -Interface - - -OptimismMintableERC721Factory - - -Security Considerations - -GovernanceToken - - - - -This upgrade enables a deterministic L2 genesis state by moving all network -specific configuration out of the initial L2 genesis state. All network specific -configuration is sourced from deposit transactions during the initialization -of the SystemConfig. -Constants -NameValueDefinition -ConfigTypeuint8An enum representing the type of config being set -WithdrawalNetworkuint8(0) or uint8(1)0 means withdraw to L1, 1 means withdraw to L2 -RECIPIENTaddressThe account that will receive funds sent out of the FeeVault -MIN_WITHDRAWAL_AMOUNTuint256The minimum amount of native asset held in the FeeVault before withdrawal is authorized -Fee Vault Configbytes32bytes32((WithdrawalNetwork << 248) || uint256(uint88(MIN_WITHDRAWAL_AMOUNT)) || uint256(uint160(RECIPIENT))) -BASE_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.basefeevaultconfig")) - 1)The Fee Vault Config for the BaseFeeVault -L1_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.l1feevaultconfig")) - 1)The Fee Vault Config for the L1FeeVault -SEQUENCER_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.sequencerfeevaultconfig")) - 1)The Fee Vault Config for the SequencerFeeVault -L1_CROSS_DOMAIN_MESSENGER_ADDRESSbytes32(uint256(keccak256("opstack.l1crossdomainmessengeraddress")) - 1)abi.encode(address(L1CrossDomainMessengerProxy)) -L1_ERC_721_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1erc721bridgeaddress")) - 1)abi.encode(address(L1ERC721BridgeProxy)) -L1_STANDARD_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1standardbridgeaddress")) - 1)abi.encode(address(L1StandardBridgeProxy)) -REMOTE_CHAIN_IDbytes32(uint256(keccak256("opstack.remotechainid")) - 1)Chain ID of the remote chain - - -Predeploys -All network specific configuration is moved to a single contract, the L1Block predeploy. -All predeploys make calls to the L1Block contract to fetch network specific configuration -rather than reading it from local state. -graph LR - subgraph L1 - SystemConfig -- "setConfig(uint8,bytes)" --> OptimismPortal - end - subgraph L2 - L1Block - BaseFeeVault -- "baseFeeVaultConfig()(address,uint256,uint8)" --> L1Block - SequencerFeeVault -- "sequencerFeeVaultConfig()(address,uint256,uint8)" --> L1Block - L1FeeVault -- "l1FeeVaultConfig()(address,uint256,uint8)" --> L1Block - L2CrossDomainMessenger -- "l1CrossDomainMessenger()(address)" --> L1Block - L2StandardBridge -- "l1StandardBridge()(address)" --> L1Block - L2ERC721Bridge -- "l1ERC721Bridge()(address)" --> L1Block - OptimismMintableERC721Factory -- "remoteChainId()(uint256)" --> L1Block - end - OptimismPortal -- "setConfig(uint8,bytes)" --> L1Block - -L1Block -Storage -The following storage slots are defined: - -BASE_FEE_VAULT_CONFIG -L1_FEE_VAULT_CONFIG -SEQUENCER_FEE_VAULT_CONFIG -L1_CROSS_DOMAIN_MESSENGER_ADDRESS -L1_ERC_721_BRIDGE_ADDRESS -L1_STANDARD_BRIDGE_ADDRESS -REMOTE_CHAIN_ID - -Each slot MUST have a defined ConfigType that authorizes the setting of the storage slot -via a deposit transaction from the DEPOSITOR_ACCOUNT. -Interface -setHolocene -This function is meant to be called once on the activation block of the holocene network upgrade. -It MUST only be callable by the DEPOSITOR_ACCOUNT once. When it is called, it MUST call -call each getter for the network specific config and set the returndata into storage. -setConfig -This function MUST only be callable by the DEPOSITOR_ACCOUNT. It modifies the storage directly -of the L1Block contract. It MUST handle all defined ConfigTypes. To ensure a simple ABI, the -bytes value MUST be abi decoded based on the ConfigType. -function setConfig(ConfigType,bytes) - -Note that ConfigType is an enum which is an alias for a uint8. -baseFeeVaultConfig -This function MUST be called by the BaseFeeVault to fetch network specific configuration. -function baseFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -sequencerFeeVaultConfig -This function MUST be called by the SequencerFeeVault to fetch network specific configuration. -function sequencerFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1FeeVaultConfig -This function MUST be called by the L1FeeVault to fetch network specific configuration. -function l1FeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1CrossDomainMessenger -This function MUST be called by the L2CrossDomainMessenger to fetch the address of the L1CrossDomainMessenger. -function l1CrossDomainMessenger()(address) - -l1StandardBridge -This function MUST be called by the L2StandardBridge to fetch the address of the L2CrossDomainMessenger. -function l1StandardBridge()(address) - -l1ERC721Bridge -This function MUST be called by the L2ERC721Bridge to fetch the address of the L1ERC721Bridge. -function l1ERC721Bridge()(address) - -remoteChainId -This function MUST be called by the OptimismMintableERC721Factory to fetch the chain id of the remote chain. -For an L2, this is the L1 chain id. -function remoteChainId()(uint256) - -FeeVault -The following changes apply to each of the BaseFeeVault, the L1FeeVault and the SequencerFeeVault. -Interface -The following functions are updated to read from the L1Block contract: - -recipient()(address) -withdrawalNetwork()(WithdrawalNetwork) -minWithdrawalAmount()(uint256) -withdraw() - -NameCall -BaseFeeVaultL1Block.baseFeeVaultConfig() -SequencerFeeVaultL1Block.sequencerFeeVaultConfig() -L1FeeVaultL1Block.l1FeeVaultConfig() - - -config -A new function is added to fetch the full Fee Vault Config. -function config()(address,uint256,WithdrawalNetwork) - -L2CrossDomainMessenger -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1CrossDomainMessenger(): - -otherMessenger()(address) -OTHER_MESSENGER()(address) - -L2ERC721Bridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1ERC721Bridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -L2StandardBridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1StandardBridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -OptimismMintableERC721Factory -The chain id is no longer read from storage but instead is read from the L1Block contract by calling -L1Block.remoteChainId() -Security Considerations -GovernanceToken -The predeploy defined by GovernanceToken should be an empty account until it is defined by -a future hardfork. +Predeploys @@ -401,7 +199,7 @@ GovernanceTok - + @@ -415,7 +213,7 @@ GovernanceTok - + diff --git a/protocol/holocene/configurability.html b/protocol/holocene/system-config.html similarity index 72% rename from protocol/holocene/configurability.html rename to protocol/holocene/system-config.html index 985283b56..0df792e3e 100644 --- a/protocol/holocene/configurability.html +++ b/protocol/holocene/system-config.html @@ -3,7 +3,7 @@ - Configurability - OP Stack Specification + System Config - OP Stack Specification @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -159,7 +159,7 @@ OP Stack Specification - + @@ -189,18 +189,12 @@ OP Stack Specification -Configurability +System Config Table of Contents -Overview -Constants - -ConfigType - - -SystemConfig +Overview ConfigUpdate Initialization @@ -214,22 +208,6 @@ Configurabili eip1559Denominator -Fee Vault Config - -setBaseFeeVaultConfig -setL1FeeVaultConfig -setSequencerFeeVaultConfig - - - - - - -OptimismPortal - -Interface - -setConfig @@ -237,23 +215,7 @@ Configurabili Overview -The SystemConfig and OptimismPortal are updated with a new flow for chain -configurability. -Constants -ConfigType -The ConfigType enum represents configuration that can be modified. -NameValueDescription -SET_GAS_PAYING_TOKENuint8(0)Modifies the gas paying token for the chain -SET_BASE_FEE_VAULT_CONFIGuint8(1)Sets the Fee Vault Config for the BaseFeeVault -SET_L1_FEE_VAULT_CONFIGuint8(2)Sets the Fee Vault Config for the L1FeeVault -SET_SEQUENCER_FEE_VAULT_CONFIGuint8(3)Sets the Fee Vault Config for the SequencerFeeVault -SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESSuint8(4)Sets the L1CrossDomainMessenger address -SET_L1_ERC_721_BRIDGE_ADDRESSuint8(5)Sets the L1ERC721Bridge address -SET_L1_STANDARD_BRIDGE_ADDRESSuint8(6)Sets the L1StandardBridge address -SET_REMOTE_CHAIN_IDuint8(7)Sets the chain id of the base chain - - -SystemConfig +The SystemConfig is updated to allow for dynamic EIP-1559 parameters. ConfigUpdate The following ConfigUpdate event is defined where the CONFIG_VERSION is uint256(0): NameValueDefinitionUsage @@ -272,16 +234,7 @@ Initialization< emit ConfigUpdate.GAS_LIMIT emit ConfigUpdate.UNSAFE_BLOCK_SIGNER emit ConfigUpdate.EIP_1559_PARAMS -setConfig(SET_GAS_PAYING_TOKEN) -setConfig(SET_BASE_FEE_VAULT_CONFIG) -setConfig(SET_L1_FEE_VAULT_CONFIG) -setConfig(SET_SEQUENCER_FEE_VAULT_CONFIG) -setConfig(SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESS) -setConfig(SET_L1_ERC_721_BRIDGE_ADDRESS) -setConfig(SET_L1_STANDARD_BRIDGE_ADDRESS) -setConfig(SET_REMOTE_CHAIN_ID) -These actions MAY only be triggered if there is a diff to the value. Modifying EIP-1559 Parameters A new SystemConfig UpdateType is introduced that enables the modification of EIP-1559 parameters. This allows for the chain @@ -302,39 +255,6 @@ e This function returns the currently configured EIP-1559 denominator. function eip1559Denominator()(uint64) -Fee Vault Config -For each FeeVault, there is a setter for its config. The arguments to the setter include -the RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork. -Each of these functions should be public and only callable by the chain governor. -Each function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType. -setBaseFeeVaultConfig -function setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork) - -setL1FeeVaultConfig -function setL1FeeVaultConfig(address,uint256,WithdrawalNetwork) - -setSequencerFeeVaultConfig -function setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork) - -OptimismPortal -The OptimismPortal is updated to emit a special system TransactionDeposited event. -Interface -setConfig -The setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig -is the single source of truth for chain operator ownership. -function setConfig(ConfigType,bytes) - -This function emits a TransactionDeposited event. -event TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData); - -The following fields are included: - -from is the DEPOSITOR_ACCOUNT -to is Predeploys.L1Block -version is uint256(0) -opaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit -is 200_000, isCreation is false and the data is abi.encodeCall(L1Block.setConfig, (_type, _value)) - diff --git a/protocol/messengers.html b/protocol/messengers.html index 5719b0eac..b0c6745a4 100644 --- a/protocol/messengers.html +++ b/protocol/messengers.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/overview.html b/protocol/overview.html index 19a171b6b..8d974911d 100644 --- a/protocol/overview.html +++ b/protocol/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/precompiles.html b/protocol/precompiles.html index 2636bcded..591225781 100644 --- a/protocol/precompiles.html +++ b/protocol/precompiles.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/predeploys.html b/protocol/predeploys.html index f69344d63..18f80ecc9 100644 --- a/protocol/predeploys.html +++ b/protocol/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/preinstalls.html b/protocol/preinstalls.html index a3e678702..de25cd1f4 100644 --- a/protocol/preinstalls.html +++ b/protocol/preinstalls.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/proposals.html b/protocol/proposals.html index 4356aed7b..c7e27aba0 100644 --- a/protocol/proposals.html +++ b/protocol/proposals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/regolith/overview.html b/protocol/regolith/overview.html index 25fb28a59..735c8d392 100644 --- a/protocol/regolith/overview.html +++ b/protocol/regolith/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node-p2p.html b/protocol/rollup-node-p2p.html index 6b7b877ad..f733fce32 100644 --- a/protocol/rollup-node-p2p.html +++ b/protocol/rollup-node-p2p.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node.html b/protocol/rollup-node.html index 7b2194855..74e7465df 100644 --- a/protocol/rollup-node.html +++ b/protocol/rollup-node.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/safe-extensions.html b/protocol/safe-extensions.html index c13615619..4601198ba 100644 --- a/protocol/safe-extensions.html +++ b/protocol/safe-extensions.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/stage-1.html b/protocol/stage-1.html index d28f06461..2659aa26c 100644 --- a/protocol/stage-1.html +++ b/protocol/stage-1.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-configuration.html b/protocol/superchain-configuration.html index ee7a3f560..6796bb40e 100644 --- a/protocol/superchain-configuration.html +++ b/protocol/superchain-configuration.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-upgrades.html b/protocol/superchain-upgrades.html index e9ac90b28..aad45a9b2 100644 --- a/protocol/superchain-upgrades.html +++ b/protocol/superchain-upgrades.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/system-config.html b/protocol/system-config.html index afbdefd92..d5fe843f1 100644 --- a/protocol/system-config.html +++ b/protocol/system-config.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/withdrawals.html b/protocol/withdrawals.html index e390c5450..8596661a9 100644 --- a/protocol/withdrawals.html +++ b/protocol/withdrawals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/root.html b/root.html index 20d712d67..bd978d50b 100644 --- a/root.html +++ b/root.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/searchindex.js b/searchindex.js index 371b06267..623744500 100644 --- a/searchindex.js +++ b/searchindex.js @@ -1 +1 @@ -Object.assign(window.search, {"doc_urls":["root.html#op-stack-specification","root.html#about-optimism","root.html#about-the-op-stack","root.html#site-navigation","background.html#background","background.html#overview","background.html#foundations","background.html#ethereum-scalability","background.html#optimistic-rollups","background.html#evm-equivalence","background.html#protocol-guarantees","background.html#liveness","background.html#validity","background.html#availability","background.html#network-participants","background.html#users","background.html#sequencers","background.html#verifiers","background.html#key-interaction-diagrams","background.html#depositing-and-sending-transactions","background.html#withdrawing","background.html#next-steps","protocol/overview.html#optimism-overview","protocol/overview.html#architecture-design-goals","protocol/overview.html#architecture-overview","protocol/overview.html#core-l1-smart-contracts","protocol/overview.html#core-l2-smart-contracts","protocol/overview.html#smart-contract-proxies","protocol/overview.html#l2-node-components","protocol/overview.html#transactionblock-propagation","protocol/overview.html#key-interactions-in-depth","protocol/overview.html#deposits","protocol/overview.html#block-derivation","protocol/overview.html#engine-api","protocol/bridges.html#standard-bridges","protocol/bridges.html#overview","protocol/bridges.html#token-depositing","protocol/bridges.html#upgradability","protocol/messengers.html#cross-domain-messengers","protocol/messengers.html#overview","protocol/messengers.html#message-passing","protocol/messengers.html#upgradability","protocol/messengers.html#message-versioning","protocol/messengers.html#message-version-0","protocol/messengers.html#message-version-1","protocol/messengers.html#backwards-compatibility-notes","protocol/deposits.html#deposits","protocol/deposits.html#overview","protocol/deposits.html#the-deposited-transaction-type","protocol/deposits.html#source-hash-computation","protocol/deposits.html#kinds-of-deposited-transactions","protocol/deposits.html#validation-and-authorization-of-deposited-transactions","protocol/deposits.html#execution","protocol/deposits.html#deposit-receipt","protocol/deposits.html#l1-attributes-deposited-transaction","protocol/deposits.html#l1-attributes-deposited-transaction-calldata","protocol/deposits.html#special-accounts-on-l2","protocol/deposits.html#l1-attributes-depositor-account","protocol/deposits.html#l1-attributes-predeployed-contract","protocol/deposits.html#user-deposited-transactions","protocol/deposits.html#deposit-contract","protocol/withdrawals.html#withdrawals","protocol/withdrawals.html#overview","protocol/withdrawals.html#withdrawal-flow","protocol/withdrawals.html#on-l2","protocol/withdrawals.html#on-l1","protocol/withdrawals.html#the-l2tol1messagepasser-contract","protocol/withdrawals.html#addresses-are-not-aliased-on-withdrawals","protocol/withdrawals.html#the-optimism-portal-contract","protocol/withdrawals.html#withdrawal-verification-and-finalization","protocol/withdrawals.html#security-considerations","protocol/withdrawals.html#key-properties-of-withdrawal-verification","protocol/withdrawals.html#handling-successfully-verified-messages-that-fail-when-relayed","protocol/withdrawals.html#optimismportal-can-send-arbitrary-messages-on-l1","protocol/guaranteed-gas-market.html#guaranteed-gas-fee-market","protocol/guaranteed-gas-market.html#overview","protocol/guaranteed-gas-market.html#gas-stipend","protocol/guaranteed-gas-market.html#default-values","protocol/guaranteed-gas-market.html#limiting-guaranteed-gas","protocol/guaranteed-gas-market.html#rationale-for-burning-l1-gas","protocol/guaranteed-gas-market.html#on-preventing-griefing-attacks","protocol/proposals.html#l2-output-root-proposals-specification","protocol/proposals.html#overview","protocol/proposals.html#proposing-l2-output-commitments","protocol/proposals.html#l2outputoracle-v100","protocol/proposals.html#l2-output-commitment-construction","protocol/proposals.html#l2-output-oracle-smart-contract","protocol/proposals.html#configuration","protocol/proposals.html#security-considerations","protocol/proposals.html#l1-reorgs","protocol/exec-engine.html#l2-execution-engine","protocol/exec-engine.html#1559-parameters","protocol/exec-engine.html#deposited-transaction-processing","protocol/exec-engine.html#deposited-transaction-boundaries","protocol/exec-engine.html#fees","protocol/exec-engine.html#fee-vaults","protocol/exec-engine.html#priority-fees-sequencer-fee-vault","protocol/exec-engine.html#base-fees-base-fee-vault","protocol/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/exec-engine.html#engine-api","protocol/exec-engine.html#engine_forkchoiceupdatedv2","protocol/exec-engine.html#engine_forkchoiceupdatedv3","protocol/exec-engine.html#engine_newpayloadv2","protocol/exec-engine.html#engine_newpayloadv3","protocol/exec-engine.html#engine_getpayloadv2","protocol/exec-engine.html#engine_getpayloadv3","protocol/exec-engine.html#engine_signalsuperchainv1","protocol/exec-engine.html#networking","protocol/exec-engine.html#sync","protocol/exec-engine.html#happy-path-sync","protocol/exec-engine.html#worst-case-sync","protocol/exec-engine.html#ecotone-disable-blob-transactions","protocol/exec-engine.html#ecotone-beacon-block-root","protocol/exec-engine.html#p2p-modifications","protocol/rollup-node.html#rollup-node-specification","protocol/rollup-node.html#overview","protocol/rollup-node.html#driver","protocol/rollup-node.html#derivation","protocol/rollup-node.html#l2-output-rpc-method","protocol/rollup-node.html#structures","protocol/rollup-node.html#output-method-api","protocol/rollup-node.html#protocol-version-tracking","protocol/rollup-node-p2p.html#rollup-node-p2p-interface","protocol/rollup-node-p2p.html#overview","protocol/rollup-node-p2p.html#p2p-configuration","protocol/rollup-node-p2p.html#identification","protocol/rollup-node-p2p.html#discv5","protocol/rollup-node-p2p.html#libp2p","protocol/rollup-node-p2p.html#gossip-topics","protocol/rollup-node-p2p.html#blocksv1","protocol/rollup-node-p2p.html#blocksv2","protocol/rollup-node-p2p.html#blocksv3","protocol/rollup-node-p2p.html#block-encoding","protocol/rollup-node-p2p.html#block-signatures","protocol/rollup-node-p2p.html#block-validation","protocol/rollup-node-p2p.html#req-resp","protocol/rollup-node-p2p.html#payload_by_number","protocol/derivation.html#l2-chain-derivation-specification","protocol/derivation.html#overview","protocol/derivation.html#eager-block-derivation","protocol/derivation.html#protocol-parameters","protocol/derivation.html#batch-submission","protocol/derivation.html#sequencing--batch-submission-overview","protocol/derivation.html#batch-submission-wire-format","protocol/derivation.html#batcher-transaction-format","protocol/derivation.html#frame-format","protocol/derivation.html#channel-format","protocol/derivation.html#batch-format","protocol/derivation.html#architecture","protocol/derivation.html#l2-chain-derivation-pipeline","protocol/derivation.html#l1-traversal","protocol/derivation.html#l1-retrieval","protocol/derivation.html#frame-queue","protocol/derivation.html#channel-bank","protocol/derivation.html#channel-reader-batch-decoding","protocol/derivation.html#batch-queue","protocol/derivation.html#payload-attributes-derivation","protocol/derivation.html#engine-queue","protocol/derivation.html#resetting-the-pipeline","protocol/derivation.html#deriving-payload-attributes","protocol/derivation.html#deriving-the-transaction-list","protocol/derivation.html#network-upgrade-automation-transactions","protocol/derivation.html#building-individual-payload-attributes","protocol/batcher.html#batch-submitter","protocol/batcher.html#overview","fault-proof/index.html#fault-proof","fault-proof/index.html#overview","fault-proof/index.html#pre-image-oracle","fault-proof/index.html#pre-image-key-types","fault-proof/index.html#bootstrapping","fault-proof/index.html#hinting","fault-proof/index.html#pre-image-communication","fault-proof/index.html#fault-proof-program","fault-proof/index.html#prologue","fault-proof/index.html#main-content","fault-proof/index.html#epilogue","fault-proof/index.html#pre-image-hinting-routes","fault-proof/index.html#precompile-accelerators","fault-proof/index.html#fault-proof-vm","fault-proof/index.html#fault-proof-interactive-dispute-game","fault-proof/cannon-fault-proof-vm.html#cannon-fault-proof-virtual-machine","fault-proof/cannon-fault-proof-vm.html#overview","fault-proof/cannon-fault-proof-vm.html#state","fault-proof/cannon-fault-proof-vm.html#state-hash","fault-proof/cannon-fault-proof-vm.html#memory","fault-proof/cannon-fault-proof-vm.html#heap","fault-proof/cannon-fault-proof-vm.html#delay-slots","fault-proof/cannon-fault-proof-vm.html#syscalls","fault-proof/cannon-fault-proof-vm.html#io","fault-proof/cannon-fault-proof-vm.html#standard-streams","fault-proof/cannon-fault-proof-vm.html#hint-communication","fault-proof/cannon-fault-proof-vm.html#pre-image-communication","fault-proof/cannon-fault-proof-vm.html#exceptions","fault-proof/cannon-fault-proof-vm.html#security-model","fault-proof/cannon-fault-proof-vm.html#compiler-correctness","fault-proof/cannon-fault-proof-vm.html#compiler-assumptions","fault-proof/stage-one/index.html#stage-one-decentralization","fault-proof/stage-one/dispute-game-interface.html#dispute-game-interface","fault-proof/stage-one/dispute-game-interface.html#overview","fault-proof/stage-one/dispute-game-interface.html#types","fault-proof/stage-one/dispute-game-interface.html#disputegamefactory-interface","fault-proof/stage-one/dispute-game-interface.html#disputegame-interface","fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game","fault-proof/stage-one/fault-dispute-game.html#overview","fault-proof/stage-one/fault-dispute-game.html#definitions","fault-proof/stage-one/fault-dispute-game.html#virtual-machine-vm","fault-proof/stage-one/fault-dispute-game.html#preimageoracle","fault-proof/stage-one/fault-dispute-game.html#execution-trace","fault-proof/stage-one/fault-dispute-game.html#claims","fault-proof/stage-one/fault-dispute-game.html#anchor-state","fault-proof/stage-one/fault-dispute-game.html#anchor-state-registry","fault-proof/stage-one/fault-dispute-game.html#dag","fault-proof/stage-one/fault-dispute-game.html#subgame","fault-proof/stage-one/fault-dispute-game.html#game-tree","fault-proof/stage-one/fault-dispute-game.html#position","fault-proof/stage-one/fault-dispute-game.html#max_clock_duration","fault-proof/stage-one/fault-dispute-game.html#clock_extension","fault-proof/stage-one/fault-dispute-game.html#freeloader-claims","fault-proof/stage-one/fault-dispute-game.html#core-game-mechanics","fault-proof/stage-one/fault-dispute-game.html#actors","fault-proof/stage-one/fault-dispute-game.html#moves","fault-proof/stage-one/fault-dispute-game.html#l2-block-number-challenge","fault-proof/stage-one/fault-dispute-game.html#step","fault-proof/stage-one/fault-dispute-game.html#step-types","fault-proof/stage-one/fault-dispute-game.html#preimageoracle-interaction","fault-proof/stage-one/fault-dispute-game.html#team-dynamics","fault-proof/stage-one/fault-dispute-game.html#game-clock","fault-proof/stage-one/fault-dispute-game.html#resolution","fault-proof/stage-one/fault-dispute-game.html#finalization","fault-proof/stage-one/honest-challenger-fdg.html#honest-challenger-fault-dispute-game","fault-proof/stage-one/honest-challenger-fdg.html#overview","fault-proof/stage-one/honest-challenger-fdg.html#invariants","fault-proof/stage-one/honest-challenger-fdg.html#fault-dispute-game-responses","fault-proof/stage-one/honest-challenger-fdg.html#moves","fault-proof/stage-one/honest-challenger-fdg.html#steps","fault-proof/stage-one/honest-challenger-fdg.html#timeliness","fault-proof/stage-one/honest-challenger-fdg.html#resolution","fault-proof/stage-one/bond-incentives.html#bond-incentives","fault-proof/stage-one/bond-incentives.html#overview","fault-proof/stage-one/bond-incentives.html#moves","fault-proof/stage-one/bond-incentives.html#subgame-resolution","fault-proof/stage-one/bond-incentives.html#leftmost-claim-incentives","fault-proof/stage-one/bond-incentives.html#fault-proof-mainnet-incentives","fault-proof/stage-one/bond-incentives.html#authenticated-roles","fault-proof/stage-one/bond-incentives.html#base-fee-assumption","fault-proof/stage-one/bond-incentives.html#bond-scaling","fault-proof/stage-one/bond-incentives.html#required-bond-formula","fault-proof/stage-one/bond-incentives.html#other-incentives","fault-proof/stage-one/bond-incentives.html#delayedweth","fault-proof/stage-one/bridge-integration.html#bridge-integration","fault-proof/stage-one/bridge-integration.html#overview","fault-proof/stage-one/bridge-integration.html#legacy-semantics","fault-proof/stage-one/bridge-integration.html#fpac-optimismportal-mods-specification","fault-proof/stage-one/bridge-integration.html#roles---optimismportal","fault-proof/stage-one/bridge-integration.html#new-deployconfig-variables","fault-proof/stage-one/bridge-integration.html#data-structures","fault-proof/stage-one/bridge-integration.html#state-layout","fault-proof/stage-one/bridge-integration.html#provewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#finalizewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#air-gap","fault-proof/stage-one/bridge-integration.html#proxy-upgrade","fault-proof/stage-one/bridge-integration.html#permissioned-faultdisputegame","fault-proof/stage-one/bridge-integration.html#roles---permissioneddisputegame","fault-proof/stage-one/bridge-integration.html#modifications","protocol/precompiles.html#precompiles","protocol/precompiles.html#overview","protocol/precompiles.html#p256verify","protocol/predeploys.html#predeploys","protocol/predeploys.html#overview","protocol/predeploys.html#legacymessagepasser","protocol/predeploys.html#l2tol1messagepasser","protocol/predeploys.html#deployerwhitelist","protocol/predeploys.html#legacyerc20eth","protocol/predeploys.html#weth9","protocol/predeploys.html#l2crossdomainmessenger","protocol/predeploys.html#l2standardbridge","protocol/predeploys.html#l1blocknumber","protocol/predeploys.html#gaspriceoracle","protocol/predeploys.html#l1block","protocol/predeploys.html#proxyadmin","protocol/predeploys.html#sequencerfeevault","protocol/predeploys.html#optimismmintableerc20factory","protocol/predeploys.html#optimismmintableerc721factory","protocol/predeploys.html#basefeevault","protocol/predeploys.html#l1feevault","protocol/predeploys.html#schemaregistry","protocol/predeploys.html#eas","protocol/predeploys.html#beacon-block-root","protocol/preinstalls.html#preinstalls","protocol/preinstalls.html#overview","protocol/preinstalls.html#safe","protocol/preinstalls.html#safel2","protocol/preinstalls.html#multisend","protocol/preinstalls.html#multisendcallonly","protocol/preinstalls.html#safesingletonfactory","protocol/preinstalls.html#multicall3","protocol/preinstalls.html#create2deployer","protocol/preinstalls.html#createx","protocol/preinstalls.html#arachnids-deterministic-deployment-proxy","protocol/preinstalls.html#permit2","protocol/preinstalls.html#erc-4337-v060-entrypoint","protocol/preinstalls.html#erc-4337-v060-sendercreator","protocol/preinstalls.html#erc-4337-v070-entrypoint","protocol/preinstalls.html#erc-4337-v070-sendercreator","protocol/superchain-configuration.html#superchain-configuration","protocol/superchain-configuration.html#overview","protocol/superchain-configuration.html#configurable-values","protocol/superchain-configuration.html#configuration-data-flow","protocol/superchain-configuration.html#pausability","protocol/superchain-upgrades.html#superchain-upgrades","protocol/superchain-upgrades.html#overview","protocol/superchain-upgrades.html#protocol-version","protocol/superchain-upgrades.html#protocol-version-format","protocol/superchain-upgrades.html#protocol-version-exposure","protocol/superchain-upgrades.html#superchain-target","protocol/superchain-upgrades.html#superchain-version-signaling","protocol/superchain-upgrades.html#protocolversions-l1-contract","protocol/superchain-upgrades.html#activation-rules","protocol/superchain-upgrades.html#l2-block-number-based-activation-deprecated","protocol/superchain-upgrades.html#l2-block-timestamp-based-activation","protocol/superchain-upgrades.html#op-stack-protocol-versions","protocol/superchain-upgrades.html#post-bedrock-network-upgrades","protocol/superchain-upgrades.html#activation-timestamps","protocol/system-config.html#system-config","protocol/system-config.html#overview","protocol/system-config.html#system-config-contents-version-0","protocol/system-config.html#batcherhash-bytes32","protocol/system-config.html#scalars","protocol/system-config.html#gaslimit-uint64","protocol/system-config.html#unsafeblocksigner-address","protocol/system-config.html#writing-the-system-config","protocol/system-config.html#reading-the-system-config","protocol/configurability.html#op-stack-configurability","protocol/configurability.html#consensus-parameters","protocol/configurability.html#batch-inbox-address","protocol/configurability.html#batcher-hash","protocol/configurability.html#chain-id","protocol/configurability.html#proof-maturity-delay","protocol/configurability.html#dispute-game-finality","protocol/configurability.html#respected-game-type","protocol/configurability.html#fault-game-max-depth","protocol/configurability.html#fault-game-split-depth","protocol/configurability.html#max-game-clock-duration","protocol/configurability.html#game-clock-extension","protocol/configurability.html#bond-withdrawal-delay","protocol/configurability.html#minimum-large-preimage-proposal-size","protocol/configurability.html#large-preimage-proposal-challenge-period","protocol/configurability.html#fault-game-absolute-prestate","protocol/configurability.html#fault-game-genesis-block","protocol/configurability.html#fault-game-genesis-output-root","protocol/configurability.html#fee-scalar","protocol/configurability.html#gas-limit","protocol/configurability.html#genesis-state","protocol/configurability.html#l2-block-time","protocol/configurability.html#resource-config","protocol/configurability.html#sequencing-window-size","protocol/configurability.html#start-block","protocol/configurability.html#superchain-target","protocol/configurability.html#governance-token","protocol/configurability.html#resource-config-1","protocol/configurability.html#policy-parameters","protocol/configurability.html#data-availability-type","protocol/configurability.html#batch-submission-frequency","protocol/configurability.html#output-frequency","protocol/configurability.html#admin-roles","protocol/configurability.html#l1-proxy-admin","protocol/configurability.html#l1-proxyadmin-owner","protocol/configurability.html#l2-proxy-admin","protocol/configurability.html#l2-proxyadmin-owner","protocol/configurability.html#system-config-owner","protocol/configurability.html#service-roles","protocol/configurability.html#batch-submitter-address","protocol/configurability.html#challenger-address","protocol/configurability.html#guardian-address","protocol/configurability.html#proposer-address","protocol/configurability.html#sequencer-p2p--unsafe-head-signer","protocol/safe-extensions.html#safe-contract-extensions","protocol/safe-extensions.html#guardian-safe","protocol/safe-extensions.html#deputy-guardian-module","protocol/safe-extensions.html#deputy-guardian-module-security-properties","protocol/safe-extensions.html#security-council-liveness-checking-extensions","protocol/safe-extensions.html#the-liveness-guard","protocol/safe-extensions.html#the-liveness-module","protocol/safe-extensions.html#owner-removal-call-flow","protocol/safe-extensions.html#shutdown","protocol/safe-extensions.html#liveness-security-properties","protocol/safe-extensions.html#interdependency-between-the-liveness-guard-and-liveness-module","protocol/safe-extensions.html#operational-considerations","protocol/safe-extensions.html#manual-validation-of-new-owner-liveness","protocol/safe-extensions.html#deploying-the-liveness-checking-system","protocol/safe-extensions.html#modifying-the-liveness-checking-system","protocol/stage-1.html#stage-1-roles-and-requirements","protocol/stage-1.html#overview","protocol/stage-1.html#permissionless-fault-proofs","protocol/stage-1.html#roles-for-stage-1","protocol/stage-1.html#configuration-of-safes","protocol/stage-1.html#ownership-model-diagram","protocol/regolith/overview.html#regolith","protocol/regolith/overview.html#overview","protocol/canyon/overview.html#canyon","protocol/canyon/overview.html#execution-layer","protocol/canyon/overview.html#consensus-layer","protocol/delta/overview.html#delta","protocol/delta/overview.html#consensus-layer","protocol/delta/span-batches.html#span-batches","protocol/delta/span-batches.html#introduction","protocol/delta/span-batches.html#span-batch-format","protocol/delta/span-batches.html#span-batch-size-limits","protocol/delta/span-batches.html#future-batch-format-extension","protocol/delta/span-batches.html#span-batch-activation-rule","protocol/delta/span-batches.html#optimization-strategies","protocol/delta/span-batches.html#truncating-information-and-storing-only-necessary-data","protocol/delta/span-batches.html#tx_data_headers-removal-from-initial-specs","protocol/delta/span-batches.html#chain-id-removal-from-initial-specs","protocol/delta/span-batches.html#reorganization-of-constant-length-transaction-fields","protocol/delta/span-batches.html#rlp-encoding-for-only-variable-length-fields","protocol/delta/span-batches.html#store-y_parity-and-protected_bit-instead-of-v","protocol/delta/span-batches.html#adjust-txs-data-layout-for-better-compression","protocol/delta/span-batches.html#fee_recipients-encoding-scheme","protocol/delta/span-batches.html#how-derivation-works-with-span-batches","protocol/delta/span-batches.html#integration","protocol/delta/span-batches.html#channel-reader-batch-decoding","protocol/delta/span-batches.html#batch-queue","protocol/delta/span-batches.html#batcher","protocol/ecotone/overview.html#ecotone-network-upgrade","protocol/ecotone/overview.html#execution-layer","protocol/ecotone/overview.html#consensus-layer","protocol/ecotone/derivation.html#derivation","protocol/ecotone/derivation.html#ecotone-blob-retrieval","protocol/ecotone/derivation.html#blob-encoding","protocol/ecotone/l1-attributes.html#ecotone-l1-attributes","protocol/ecotone/l1-attributes.html#overview","protocol/ecotone/l1-attributes.html#l1-attributes-predeployed-contract","protocol/ecotone/l1-attributes.html#ecotone-l1block-upgrade","protocol/fjord/overview.html#fjord-network-upgrade","protocol/fjord/overview.html#execution-layer","protocol/fjord/overview.html#consensus-layer","protocol/fjord/exec-engine.html#l2-execution-engine","protocol/fjord/exec-engine.html#fees","protocol/fjord/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/fjord/exec-engine.html#l1-gas-usage-estimation","protocol/fjord/derivation.html#fjord-l2-chain-derivation-changes","protocol/fjord/derivation.html#protocol-parameter-changes","protocol/fjord/derivation.html#timestamp-activation","protocol/fjord/derivation.html#constant-maximum-sequencer-drift","protocol/fjord/derivation.html#rationale","protocol/fjord/derivation.html#security-considerations","protocol/fjord/derivation.html#increasing-max_rlp_bytes_per_channel-and-max_channel_bank_size","protocol/fjord/derivation.html#rationale-1","protocol/fjord/derivation.html#security-considerations-1","protocol/fjord/derivation.html#brotli-channel-compression","protocol/fjord/derivation.html#network-upgrade-automation-transactions","protocol/fjord/derivation.html#gaspriceoracle-deployment","protocol/fjord/derivation.html#gaspriceoracle-proxy-update","protocol/fjord/derivation.html#gaspriceoracle-enable-fjord","protocol/fjord/predeploys.html#predeploys","protocol/fjord/predeploys.html#gaspriceoracle","protocol/fjord/predeploys.html#l1-gas-usage-estimation","protocol/granite/overview.html#granite-network-upgrade","protocol/granite/overview.html#execution-layer","protocol/granite/overview.html#consensus-layer","protocol/granite/exec-engine.html#l2-execution-engine","protocol/granite/exec-engine.html#evm-changes","protocol/granite/exec-engine.html#bn256pairing-precompile-input-restriction","protocol/granite/derivation.html#granite-l2-chain-derivation-changes","protocol/granite/derivation.html#protocol-parameter-changes","protocol/granite/derivation.html#reduce-channel-timeout","protocol/holocene/overview.html#holocene-network-upgrade","protocol/holocene/overview.html#execution-layer","protocol/holocene/overview.html#consensus-layer","protocol/holocene/overview.html#smart-contracts","protocol/holocene/derivation.html#holocene-l2-chain-derivation-changes","protocol/holocene/derivation.html#holocene-derivation","protocol/holocene/derivation.html#summary","protocol/holocene/derivation.html#frame-queue","protocol/holocene/derivation.html#channel-bank","protocol/holocene/derivation.html#pruning","protocol/holocene/derivation.html#timeout","protocol/holocene/derivation.html#reading--frame-loading","protocol/holocene/derivation.html#span-batches","protocol/holocene/derivation.html#batch-queue","protocol/holocene/derivation.html#fast-channel-invalidation","protocol/holocene/derivation.html#engine-queue","protocol/holocene/derivation.html#attributes-builder","protocol/holocene/derivation.html#activation","protocol/holocene/derivation.html#rationale","protocol/holocene/derivation.html#strict-frame-and-batch-ordering","protocol/holocene/derivation.html#partial-span-batch-validity","protocol/holocene/derivation.html#fast-channel-invalidation-1","protocol/holocene/derivation.html#steady-block-derivation","protocol/holocene/derivation.html#less-defensive-protocol","protocol/holocene/derivation.html#security-and-implementation-considerations","protocol/holocene/derivation.html#reorgs","protocol/holocene/derivation.html#batcher-hardening","protocol/holocene/derivation.html#sync-start","protocol/holocene/exec-engine.html#l2-execution-engine","protocol/holocene/exec-engine.html#timestamp-activation","protocol/holocene/exec-engine.html#l2tol1messagepasser-storage-root-in-header","protocol/holocene/exec-engine.html#header-validity-rules","protocol/holocene/exec-engine.html#header-withdrawals-root","protocol/holocene/exec-engine.html#extended-payloadattributesv3","protocol/holocene/exec-engine.html#eip1559params-encoding","protocol/holocene/exec-engine.html#execution","protocol/holocene/exec-engine.html#rationale","protocol/holocene/exec-engine.html#eip1559params-in-header","protocol/holocene/exec-engine.html#header-validity-rules-1","protocol/holocene/exec-engine.html#encoding","protocol/holocene/exec-engine.html#rationale-1","protocol/holocene/predeploys.html#overview","protocol/holocene/predeploys.html#constants","protocol/holocene/predeploys.html#predeploys","protocol/holocene/predeploys.html#l1block","protocol/holocene/predeploys.html#feevault","protocol/holocene/predeploys.html#l2crossdomainmessenger","protocol/holocene/predeploys.html#l2erc721bridge","protocol/holocene/predeploys.html#l2standardbridge","protocol/holocene/predeploys.html#optimismmintableerc721factory","protocol/holocene/predeploys.html#security-considerations","protocol/holocene/predeploys.html#governancetoken","protocol/holocene/configurability.html#configurability","protocol/holocene/configurability.html#overview","protocol/holocene/configurability.html#constants","protocol/holocene/configurability.html#configtype","protocol/holocene/configurability.html#systemconfig","protocol/holocene/configurability.html#configupdate","protocol/holocene/configurability.html#initialization","protocol/holocene/configurability.html#modifying-eip-1559-parameters","protocol/holocene/configurability.html#interface","protocol/holocene/configurability.html#optimismportal","protocol/holocene/configurability.html#interface-1","governance/gov-token.html#governance-token","governance/gov-token.html#overview","governance/gov-token.html#token-minting","governance/gov-token.html#token-burning","governance/gov-token.html#voting-power","governance/gov-token.html#delegation","experimental/custom-gas-token.html#custom-gas-token","experimental/custom-gas-token.html#overview","experimental/custom-gas-token.html#constants","experimental/custom-gas-token.html#properties-of-a-gas-paying-token","experimental/custom-gas-token.html#automated-validation","experimental/custom-gas-token.html#configuring-the-gas-paying-token","experimental/custom-gas-token.html#contract-modifications","experimental/custom-gas-token.html#igastoken-interface","experimental/custom-gas-token.html#gas-token-aware","experimental/custom-gas-token.html#optimismportal","experimental/custom-gas-token.html#standardbridge","experimental/custom-gas-token.html#crossdomainmessenger","experimental/custom-gas-token.html#systemconfig","experimental/custom-gas-token.html#l1block","experimental/custom-gas-token.html#weth9","experimental/custom-gas-token.html#user-flow","experimental/custom-gas-token.html#when-eth-is-the-native-asset","experimental/custom-gas-token.html#when-an-erc20-token-is-the-native-asset","experimental/custom-gas-token.html#differences","experimental/custom-gas-token.html#upgrade","experimental/custom-gas-token.html#l1block-deployment","experimental/custom-gas-token.html#l2crossdomainmessenger-deployment","experimental/custom-gas-token.html#l2standardbridge-deployment","experimental/custom-gas-token.html#l1block-proxy-update","experimental/custom-gas-token.html#l2crossdomainmessenger-proxy-update","experimental/custom-gas-token.html#l2standardbridge-proxy-update","experimental/custom-gas-token.html#selection-of-ether_token_address","experimental/custom-gas-token.html#standard-config","experimental/custom-gas-token.html#fees","experimental/custom-gas-token.html#security-considerations","experimental/custom-gas-token.html#optimismportal-token-allowance","experimental/custom-gas-token.html#interoperability-support","experimental/custom-gas-token.html#wrapped-ether","experimental/alt-da.html#alt-da-mode","experimental/alt-da.html#overview","experimental/alt-da.html#input-commitment-submission","experimental/alt-da.html#da-server","experimental/alt-da.html#data-availability-challenge-contract","experimental/alt-da.html#parameters","experimental/alt-da.html#derivation","experimental/alt-da.html#fault-proof","experimental/alt-da.html#l2-input","experimental/alt-da.html#l1-challenge-status","experimental/alt-da.html#safety-and-finality","experimental/alt-da.html#security-considerations","interop/overview.html#interop","interop/overview.html#specifications","interop/dependency-set.html#the-dependency-set","interop/dependency-set.html#chain-id","interop/dependency-set.html#updating-the-dependency-set","interop/dependency-set.html#security-considerations","interop/dependency-set.html#layer-1-as-part-of-the-dependency-set","interop/messaging.html#messaging","interop/messaging.html#message","interop/messaging.html#message-payload","interop/messaging.html#message-identifier","interop/messaging.html#messaging-ends","interop/messaging.html#initiating-messages","interop/messaging.html#executing-messages","interop/messaging.html#messaging-invariants","interop/messaging.html#timestamp-invariant","interop/messaging.html#chainid-invariant","interop/messaging.html#message-expiry-invariant","interop/messaging.html#message-graph","interop/messaging.html#invalid-messages","interop/messaging.html#intra-block-messaging-cycles","interop/messaging.html#resolving-cross-chain-safety","interop/messaging.html#horizon-timestamp","interop/messaging.html#pruning-the-graph","interop/messaging.html#bounding-the-graph","interop/messaging.html#security-considerations","interop/messaging.html#cyclic-dependencies","interop/messaging.html#transitive-dependencies","interop/predeploys.html#predeploys","interop/predeploys.html#crossl2inbox","interop/predeploys.html#functions","interop/predeploys.html#interop-start-timestamp","interop/predeploys.html#executingmessage-event","interop/predeploys.html#reference-implementation","interop/predeploys.html#deposit-handling","interop/predeploys.html#identifier-getters","interop/predeploys.html#l2tol2crossdomainmessenger","interop/predeploys.html#relaymessage-invariants","interop/predeploys.html#sendexpire-invariants","interop/predeploys.html#relayexpire-invariants","interop/predeploys.html#message-versioning","interop/predeploys.html#no-native-support-for-cross-chain-ether-sends","interop/predeploys.html#interfaces","interop/predeploys.html#optimismsuperchainerc20factory","interop/predeploys.html#optimismsuperchainerc20","interop/predeploys.html#overview","interop/predeploys.html#functions-1","interop/predeploys.html#events","interop/predeploys.html#deployment-flow","interop/predeploys.html#beaconcontract","interop/predeploys.html#overview-1","interop/predeploys.html#l1block","interop/predeploys.html#static-configuration","interop/predeploys.html#dependency-set","interop/predeploys.html#deposit-context","interop/predeploys.html#isdeposit","interop/predeploys.html#optimismmintableerc20factory","interop/predeploys.html#optimismmintableerc20","interop/predeploys.html#updates","interop/predeploys.html#functions-2","interop/predeploys.html#events-1","interop/predeploys.html#l2standardbridge","interop/predeploys.html#updates-1","interop/predeploys.html#invariants","interop/predeploys.html#conversion-flow","interop/predeploys.html#superchainerc20bridge","interop/predeploys.html#overview-2","interop/predeploys.html#functions-3","interop/predeploys.html#events-2","interop/predeploys.html#diagram","interop/predeploys.html#invariants-1","interop/predeploys.html#security-considerations","interop/sequencer.html#sequencer","interop/sequencer.html#sequencer-policy","interop/sequencer.html#block-building","interop/sequencer.html#static-analysis","interop/sequencer.html#dependency-confirmations","interop/sequencer.html#sponsorship","interop/sequencer.html#security-considerations","interop/sequencer.html#cross-chain-message-latency","interop/verifier.html#verifier","interop/verifier.html#derivation-pipeline","interop/verifier.html#depositing-an-executing-message","interop/verifier.html#safety","interop/verifier.html#honest-verifier","interop/verifier.html#security-considerations","interop/verifier.html#forced-inclusion-of-cross-chain-messages","interop/verifier.html#reliance-on-history","interop/rollup-node-p2p.html#p2p-networking","interop/rollup-node-p2p.html#security-considerations","interop/fault-proof.html#fault-proof","interop/fault-proof.html#cascading-dependencies","interop/fault-proof.html#security-considerations","interop/upgrade.html#interop-network-upgrade","interop/upgrade.html#l1-attributes","interop/upgrade.html#l1-attributes-predeployed-contract","interop/upgrade.html#interop-l1block-upgrade","interop/upgrade.html#security-considerations","interop/token-bridging.html#token-bridging","interop/token-bridging.html#overview","interop/token-bridging.html#superchainerc20-standard","interop/token-bridging.html#properties","interop/token-bridging.html#interface","interop/token-bridging.html#superchainerc20bridge","interop/token-bridging.html#diagram","interop/token-bridging.html#implementation","interop/token-bridging.html#future-considerations","interop/token-bridging.html#cross-chain-transferfrom","interop/token-bridging.html#concatenated-action","interop/superchain-weth.html#superchain-weth","interop/superchain-weth.html#motivation-and-constraints","interop/superchain-weth.html#handling-native-assets-other-than-eth","interop/superchain-weth.html#minimizing-protocol-complexity","interop/superchain-weth.html#constants","interop/superchain-weth.html#superchainweth","interop/superchain-weth.html#invariants","interop/superchain-weth.html#ethliquidity","interop/superchain-weth.html#invariants-1","interop/derivation.html#derivation","interop/derivation.html#overview","interop/derivation.html#deposit-context","interop/derivation.html#security-considerations","interop/derivation.html#gas-considerations","interop/tx-pool.html#transaction-pool","interop/tx-pool.html#message-validation","interop/tx-pool.html#system-deposits-transaction-margin","interop/tx-pool.html#security-considerations","interop/tx-pool.html#mempool-denial-of-service","experimental/op-contracts-manager.html#op-contracts-manager","experimental/op-contracts-manager.html#deployment","experimental/op-contracts-manager.html#interface","experimental/op-contracts-manager.html#proxysol","experimental/op-contracts-manager.html#deploy","experimental/op-contracts-manager.html#getter-methods","experimental/op-contracts-manager.html#implementation","experimental/op-contracts-manager.html#batch-inbox-address","experimental/op-contracts-manager.html#contract-deployments","experimental/op-contracts-manager.html#security-considerations","experimental/op-contracts-manager.html#chain-id-source-of-truth","experimental/op-contracts-manager.html#chain-id-frontrunning","experimental/op-contracts-manager.html#chain-id-value","experimental/op-contracts-manager.html#proxy-admin-owner","experimental/op-contracts-manager.html#upgradeability-abi-changes","experimental/gov-token.html#governance-token","experimental/gov-token.html#overview","experimental/gov-token.html#hook-based-integration-with-governancedelegation","experimental/gov-token.html#token-minting","experimental/gov-token.html#token-burning","experimental/gov-token.html#voting-power","experimental/gov-token.html#delegation","glossary.html#glossary","glossary.html#general-terms","glossary.html#layer-1-l1","glossary.html#layer-2-l2","glossary.html#block","glossary.html#eoa","glossary.html#merkle-patricia-trie","glossary.html#chain-re-organization","glossary.html#predeployed-contract-predeploy","glossary.html#preinstalled-contract-preinstall","glossary.html#precompiled-contract-precompile","glossary.html#receipt","glossary.html#transaction-type","glossary.html#fork-choice-rule","glossary.html#priority-gas-auction","glossary.html#sequencing","glossary.html#sequencer","glossary.html#sequencing-window","glossary.html#sequencing-epoch","glossary.html#l1-origin","glossary.html#deposits","glossary.html#deposited-transaction","glossary.html#l1-attributes-deposited-transaction","glossary.html#user-deposited-transaction","glossary.html#depositing-call","glossary.html#depositing-transaction","glossary.html#depositor","glossary.html#deposited-transaction-type","glossary.html#deposit-contract","glossary.html#withdrawals","glossary.html#relayer","glossary.html#finalization-period","glossary.html#batch-submission","glossary.html#data-availability","glossary.html#data-availability-provider","glossary.html#sequencer-batch","glossary.html#channel","glossary.html#channel-frame","glossary.html#batcher","glossary.html#batcher-transaction","glossary.html#batch-submission-frequency","glossary.html#channel-timeout","glossary.html#l2-output-root-proposals","glossary.html#proposer","glossary.html#l2-chain-derivation","glossary.html#l2-derivation-inputs","glossary.html#system-configuration","glossary.html#payload-attributes","glossary.html#l2-genesis-block","glossary.html#l2-chain-inception","glossary.html#safe-l2-block","glossary.html#safe-l2-head","glossary.html#unsafe-l2-block","glossary.html#unsafe-l2-head","glossary.html#unsafe-block-consolidation","glossary.html#finalized-l2-head","glossary.html#other-l2-chain-concepts","glossary.html#address-aliasing","glossary.html#rollup-node","glossary.html#rollup-driver","glossary.html#l1-attributes-predeployed-contract","glossary.html#l2-output-root","glossary.html#l2-output-oracle-contract","glossary.html#validator","glossary.html#fault-proof","glossary.html#time-slot","glossary.html#block-time","glossary.html#unsafe-sync","glossary.html#execution-engine-concepts","glossary.html#execution-engine"],"index":{"documentStore":{"docInfo":{"0":{"body":7,"breadcrumbs":4,"title":3},"1":{"body":51,"breadcrumbs":2,"title":1},"10":{"body":17,"breadcrumbs":3,"title":2},"100":{"body":260,"breadcrumbs":7,"title":1},"101":{"body":81,"breadcrumbs":7,"title":1},"102":{"body":7,"breadcrumbs":7,"title":1},"103":{"body":30,"breadcrumbs":7,"title":1},"104":{"body":9,"breadcrumbs":7,"title":1},"105":{"body":36,"breadcrumbs":7,"title":1},"106":{"body":72,"breadcrumbs":7,"title":1},"107":{"body":99,"breadcrumbs":7,"title":1},"108":{"body":53,"breadcrumbs":7,"title":1},"109":{"body":99,"breadcrumbs":9,"title":3},"11":{"body":33,"breadcrumbs":2,"title":1},"110":{"body":47,"breadcrumbs":9,"title":3},"111":{"body":97,"breadcrumbs":10,"title":4},"112":{"body":80,"breadcrumbs":10,"title":4},"113":{"body":31,"breadcrumbs":8,"title":2},"114":{"body":20,"breadcrumbs":9,"title":3},"115":{"body":26,"breadcrumbs":7,"title":1},"116":{"body":26,"breadcrumbs":7,"title":1},"117":{"body":85,"breadcrumbs":7,"title":1},"118":{"body":13,"breadcrumbs":10,"title":4},"119":{"body":112,"breadcrumbs":7,"title":1},"12":{"body":30,"breadcrumbs":2,"title":1},"120":{"body":57,"breadcrumbs":9,"title":3},"121":{"body":61,"breadcrumbs":9,"title":3},"122":{"body":60,"breadcrumbs":13,"title":4},"123":{"body":143,"breadcrumbs":10,"title":1},"124":{"body":0,"breadcrumbs":11,"title":2},"125":{"body":69,"breadcrumbs":10,"title":1},"126":{"body":149,"breadcrumbs":10,"title":1},"127":{"body":576,"breadcrumbs":10,"title":1},"128":{"body":9,"breadcrumbs":11,"title":2},"129":{"body":5,"breadcrumbs":10,"title":1},"13":{"body":29,"breadcrumbs":2,"title":1},"130":{"body":4,"breadcrumbs":10,"title":1},"131":{"body":4,"breadcrumbs":10,"title":1},"132":{"body":71,"breadcrumbs":11,"title":2},"133":{"body":42,"breadcrumbs":11,"title":2},"134":{"body":233,"breadcrumbs":11,"title":2},"135":{"body":167,"breadcrumbs":11,"title":2},"136":{"body":255,"breadcrumbs":10,"title":1},"137":{"body":130,"breadcrumbs":11,"title":4},"138":{"body":420,"breadcrumbs":8,"title":1},"139":{"body":59,"breadcrumbs":10,"title":3},"14":{"body":84,"breadcrumbs":3,"title":2},"140":{"body":49,"breadcrumbs":9,"title":2},"141":{"body":0,"breadcrumbs":9,"title":2},"142":{"body":147,"breadcrumbs":11,"title":4},"143":{"body":478,"breadcrumbs":11,"title":4},"144":{"body":64,"breadcrumbs":10,"title":3},"145":{"body":115,"breadcrumbs":9,"title":2},"146":{"body":133,"breadcrumbs":9,"title":2},"147":{"body":120,"breadcrumbs":9,"title":2},"148":{"body":33,"breadcrumbs":8,"title":1},"149":{"body":143,"breadcrumbs":11,"title":4},"15":{"body":18,"breadcrumbs":2,"title":1},"150":{"body":47,"breadcrumbs":9,"title":2},"151":{"body":68,"breadcrumbs":9,"title":2},"152":{"body":20,"breadcrumbs":9,"title":2},"153":{"body":311,"breadcrumbs":9,"title":2},"154":{"body":19,"breadcrumbs":11,"title":4},"155":{"body":480,"breadcrumbs":9,"title":2},"156":{"body":57,"breadcrumbs":10,"title":3},"157":{"body":874,"breadcrumbs":9,"title":2},"158":{"body":581,"breadcrumbs":9,"title":2},"159":{"body":43,"breadcrumbs":10,"title":3},"16":{"body":103,"breadcrumbs":2,"title":1},"160":{"body":140,"breadcrumbs":10,"title":3},"161":{"body":700,"breadcrumbs":11,"title":4},"162":{"body":65,"breadcrumbs":11,"title":4},"163":{"body":3,"breadcrumbs":8,"title":2},"164":{"body":116,"breadcrumbs":7,"title":1},"165":{"body":114,"breadcrumbs":7,"title":2},"166":{"body":77,"breadcrumbs":6,"title":1},"167":{"body":52,"breadcrumbs":8,"title":3},"168":{"body":548,"breadcrumbs":9,"title":4},"169":{"body":51,"breadcrumbs":6,"title":1},"17":{"body":62,"breadcrumbs":2,"title":1},"170":{"body":215,"breadcrumbs":6,"title":1},"171":{"body":128,"breadcrumbs":8,"title":3},"172":{"body":55,"breadcrumbs":8,"title":3},"173":{"body":146,"breadcrumbs":6,"title":1},"174":{"body":252,"breadcrumbs":7,"title":2},"175":{"body":142,"breadcrumbs":6,"title":1},"176":{"body":190,"breadcrumbs":9,"title":4},"177":{"body":55,"breadcrumbs":7,"title":2},"178":{"body":104,"breadcrumbs":8,"title":3},"179":{"body":88,"breadcrumbs":10,"title":5},"18":{"body":0,"breadcrumbs":4,"title":3},"180":{"body":30,"breadcrumbs":14,"title":5},"181":{"body":75,"breadcrumbs":10,"title":1},"182":{"body":116,"breadcrumbs":10,"title":1},"183":{"body":51,"breadcrumbs":11,"title":2},"184":{"body":59,"breadcrumbs":10,"title":1},"185":{"body":82,"breadcrumbs":10,"title":1},"186":{"body":63,"breadcrumbs":11,"title":2},"187":{"body":165,"breadcrumbs":10,"title":1},"188":{"body":126,"breadcrumbs":10,"title":1},"189":{"body":26,"breadcrumbs":11,"title":2},"19":{"body":93,"breadcrumbs":4,"title":3},"190":{"body":22,"breadcrumbs":11,"title":2},"191":{"body":162,"breadcrumbs":12,"title":3},"192":{"body":68,"breadcrumbs":10,"title":1},"193":{"body":0,"breadcrumbs":11,"title":2},"194":{"body":147,"breadcrumbs":11,"title":2},"195":{"body":121,"breadcrumbs":11,"title":2},"196":{"body":19,"breadcrumbs":11,"title":3},"197":{"body":8,"breadcrumbs":14,"title":3},"198":{"body":74,"breadcrumbs":12,"title":1},"199":{"body":179,"breadcrumbs":12,"title":1},"2":{"body":28,"breadcrumbs":3,"title":2},"20":{"body":141,"breadcrumbs":2,"title":1},"200":{"body":614,"breadcrumbs":13,"title":2},"201":{"body":348,"breadcrumbs":13,"title":2},"202":{"body":52,"breadcrumbs":14,"title":3},"203":{"body":79,"breadcrumbs":12,"title":1},"204":{"body":0,"breadcrumbs":12,"title":1},"205":{"body":44,"breadcrumbs":14,"title":3},"206":{"body":31,"breadcrumbs":12,"title":1},"207":{"body":25,"breadcrumbs":13,"title":2},"208":{"body":64,"breadcrumbs":12,"title":1},"209":{"body":78,"breadcrumbs":13,"title":2},"21":{"body":19,"breadcrumbs":3,"title":2},"210":{"body":29,"breadcrumbs":14,"title":3},"211":{"body":34,"breadcrumbs":12,"title":1},"212":{"body":80,"breadcrumbs":12,"title":1},"213":{"body":68,"breadcrumbs":13,"title":2},"214":{"body":112,"breadcrumbs":12,"title":1},"215":{"body":12,"breadcrumbs":12,"title":1},"216":{"body":15,"breadcrumbs":12,"title":1},"217":{"body":92,"breadcrumbs":13,"title":2},"218":{"body":22,"breadcrumbs":14,"title":3},"219":{"body":32,"breadcrumbs":12,"title":1},"22":{"body":72,"breadcrumbs":5,"title":2},"220":{"body":216,"breadcrumbs":12,"title":1},"221":{"body":110,"breadcrumbs":15,"title":4},"222":{"body":122,"breadcrumbs":12,"title":1},"223":{"body":123,"breadcrumbs":13,"title":2},"224":{"body":428,"breadcrumbs":13,"title":2},"225":{"body":58,"breadcrumbs":13,"title":2},"226":{"body":128,"breadcrumbs":13,"title":2},"227":{"body":229,"breadcrumbs":12,"title":1},"228":{"body":87,"breadcrumbs":12,"title":1},"229":{"body":12,"breadcrumbs":18,"title":5},"23":{"body":98,"breadcrumbs":6,"title":3},"230":{"body":90,"breadcrumbs":14,"title":1},"231":{"body":39,"breadcrumbs":14,"title":1},"232":{"body":93,"breadcrumbs":17,"title":4},"233":{"body":52,"breadcrumbs":14,"title":1},"234":{"body":65,"breadcrumbs":14,"title":1},"235":{"body":11,"breadcrumbs":14,"title":1},"236":{"body":64,"breadcrumbs":14,"title":1},"237":{"body":31,"breadcrumbs":15,"title":2},"238":{"body":65,"breadcrumbs":14,"title":1},"239":{"body":60,"breadcrumbs":14,"title":1},"24":{"body":0,"breadcrumbs":5,"title":2},"240":{"body":42,"breadcrumbs":15,"title":2},"241":{"body":53,"breadcrumbs":16,"title":3},"242":{"body":15,"breadcrumbs":17,"title":4},"243":{"body":27,"breadcrumbs":15,"title":2},"244":{"body":37,"breadcrumbs":16,"title":3},"245":{"body":90,"breadcrumbs":15,"title":2},"246":{"body":23,"breadcrumbs":16,"title":3},"247":{"body":31,"breadcrumbs":14,"title":1},"248":{"body":367,"breadcrumbs":14,"title":1},"249":{"body":54,"breadcrumbs":12,"title":2},"25":{"body":394,"breadcrumbs":7,"title":4},"250":{"body":27,"breadcrumbs":11,"title":1},"251":{"body":151,"breadcrumbs":12,"title":2},"252":{"body":0,"breadcrumbs":14,"title":4},"253":{"body":10,"breadcrumbs":12,"title":2},"254":{"body":39,"breadcrumbs":13,"title":3},"255":{"body":42,"breadcrumbs":12,"title":2},"256":{"body":96,"breadcrumbs":12,"title":2},"257":{"body":168,"breadcrumbs":12,"title":2},"258":{"body":122,"breadcrumbs":12,"title":2},"259":{"body":168,"breadcrumbs":12,"title":2},"26":{"body":251,"breadcrumbs":7,"title":4},"260":{"body":23,"breadcrumbs":12,"title":2},"261":{"body":43,"breadcrumbs":12,"title":2},"262":{"body":12,"breadcrumbs":12,"title":2},"263":{"body":43,"breadcrumbs":11,"title":1},"264":{"body":4,"breadcrumbs":5,"title":1},"265":{"body":61,"breadcrumbs":5,"title":1},"266":{"body":35,"breadcrumbs":5,"title":1},"267":{"body":24,"breadcrumbs":5,"title":1},"268":{"body":168,"breadcrumbs":5,"title":1},"269":{"body":71,"breadcrumbs":5,"title":1},"27":{"body":70,"breadcrumbs":6,"title":3},"270":{"body":33,"breadcrumbs":5,"title":1},"271":{"body":48,"breadcrumbs":5,"title":1},"272":{"body":41,"breadcrumbs":5,"title":1},"273":{"body":19,"breadcrumbs":5,"title":1},"274":{"body":59,"breadcrumbs":5,"title":1},"275":{"body":84,"breadcrumbs":5,"title":1},"276":{"body":30,"breadcrumbs":5,"title":1},"277":{"body":141,"breadcrumbs":5,"title":1},"278":{"body":16,"breadcrumbs":5,"title":1},"279":{"body":18,"breadcrumbs":5,"title":1},"28":{"body":142,"breadcrumbs":6,"title":3},"280":{"body":29,"breadcrumbs":5,"title":1},"281":{"body":43,"breadcrumbs":5,"title":1},"282":{"body":14,"breadcrumbs":5,"title":1},"283":{"body":25,"breadcrumbs":5,"title":1},"284":{"body":21,"breadcrumbs":5,"title":1},"285":{"body":13,"breadcrumbs":5,"title":1},"286":{"body":10,"breadcrumbs":5,"title":1},"287":{"body":18,"breadcrumbs":7,"title":3},"288":{"body":32,"breadcrumbs":5,"title":1},"289":{"body":96,"breadcrumbs":5,"title":1},"29":{"body":56,"breadcrumbs":5,"title":2},"290":{"body":18,"breadcrumbs":5,"title":1},"291":{"body":16,"breadcrumbs":5,"title":1},"292":{"body":8,"breadcrumbs":5,"title":1},"293":{"body":9,"breadcrumbs":5,"title":1},"294":{"body":51,"breadcrumbs":5,"title":1},"295":{"body":24,"breadcrumbs":5,"title":1},"296":{"body":127,"breadcrumbs":5,"title":1},"297":{"body":26,"breadcrumbs":5,"title":1},"298":{"body":87,"breadcrumbs":8,"title":4},"299":{"body":22,"breadcrumbs":5,"title":1},"3":{"body":17,"breadcrumbs":3,"title":2},"30":{"body":0,"breadcrumbs":6,"title":3},"300":{"body":12,"breadcrumbs":8,"title":4},"301":{"body":14,"breadcrumbs":8,"title":4},"302":{"body":12,"breadcrumbs":8,"title":4},"303":{"body":14,"breadcrumbs":8,"title":4},"304":{"body":13,"breadcrumbs":8,"title":2},"305":{"body":14,"breadcrumbs":7,"title":1},"306":{"body":25,"breadcrumbs":8,"title":2},"307":{"body":29,"breadcrumbs":9,"title":3},"308":{"body":70,"breadcrumbs":7,"title":1},"309":{"body":52,"breadcrumbs":8,"title":2},"31":{"body":69,"breadcrumbs":4,"title":1},"310":{"body":57,"breadcrumbs":7,"title":1},"311":{"body":123,"breadcrumbs":8,"title":2},"312":{"body":326,"breadcrumbs":9,"title":3},"313":{"body":36,"breadcrumbs":9,"title":3},"314":{"body":42,"breadcrumbs":8,"title":2},"315":{"body":88,"breadcrumbs":9,"title":3},"316":{"body":47,"breadcrumbs":9,"title":3},"317":{"body":58,"breadcrumbs":8,"title":2},"318":{"body":72,"breadcrumbs":12,"title":6},"319":{"body":100,"breadcrumbs":11,"title":5},"32":{"body":326,"breadcrumbs":5,"title":2},"320":{"body":130,"breadcrumbs":10,"title":4},"321":{"body":0,"breadcrumbs":10,"title":4},"322":{"body":49,"breadcrumbs":8,"title":2},"323":{"body":31,"breadcrumbs":7,"title":2},"324":{"body":19,"breadcrumbs":6,"title":1},"325":{"body":8,"breadcrumbs":10,"title":5},"326":{"body":43,"breadcrumbs":7,"title":2},"327":{"body":287,"breadcrumbs":6,"title":1},"328":{"body":51,"breadcrumbs":7,"title":2},"329":{"body":51,"breadcrumbs":7,"title":2},"33":{"body":139,"breadcrumbs":5,"title":2},"330":{"body":33,"breadcrumbs":8,"title":3},"331":{"body":219,"breadcrumbs":8,"title":3},"332":{"body":256,"breadcrumbs":7,"title":3},"333":{"body":0,"breadcrumbs":6,"title":2},"334":{"body":26,"breadcrumbs":7,"title":3},"335":{"body":22,"breadcrumbs":6,"title":2},"336":{"body":29,"breadcrumbs":6,"title":2},"337":{"body":41,"breadcrumbs":7,"title":3},"338":{"body":34,"breadcrumbs":7,"title":3},"339":{"body":31,"breadcrumbs":7,"title":3},"34":{"body":6,"breadcrumbs":6,"title":2},"340":{"body":25,"breadcrumbs":8,"title":4},"341":{"body":32,"breadcrumbs":8,"title":4},"342":{"body":26,"breadcrumbs":8,"title":4},"343":{"body":27,"breadcrumbs":7,"title":3},"344":{"body":27,"breadcrumbs":7,"title":3},"345":{"body":36,"breadcrumbs":9,"title":5},"346":{"body":28,"breadcrumbs":9,"title":5},"347":{"body":34,"breadcrumbs":8,"title":4},"348":{"body":30,"breadcrumbs":8,"title":4},"349":{"body":18,"breadcrumbs":9,"title":5},"35":{"body":186,"breadcrumbs":5,"title":1},"350":{"body":20,"breadcrumbs":6,"title":2},"351":{"body":31,"breadcrumbs":6,"title":2},"352":{"body":29,"breadcrumbs":6,"title":2},"353":{"body":24,"breadcrumbs":7,"title":3},"354":{"body":26,"breadcrumbs":6,"title":2},"355":{"body":48,"breadcrumbs":7,"title":3},"356":{"body":19,"breadcrumbs":6,"title":2},"357":{"body":35,"breadcrumbs":6,"title":2},"358":{"body":23,"breadcrumbs":6,"title":2},"359":{"body":18,"breadcrumbs":6,"title":2},"36":{"body":24,"breadcrumbs":6,"title":2},"360":{"body":0,"breadcrumbs":6,"title":2},"361":{"body":34,"breadcrumbs":7,"title":3},"362":{"body":48,"breadcrumbs":7,"title":3},"363":{"body":39,"breadcrumbs":6,"title":2},"364":{"body":0,"breadcrumbs":6,"title":2},"365":{"body":52,"breadcrumbs":7,"title":3},"366":{"body":20,"breadcrumbs":7,"title":3},"367":{"body":31,"breadcrumbs":7,"title":3},"368":{"body":37,"breadcrumbs":7,"title":3},"369":{"body":83,"breadcrumbs":7,"title":3},"37":{"body":8,"breadcrumbs":5,"title":1},"370":{"body":0,"breadcrumbs":6,"title":2},"371":{"body":15,"breadcrumbs":7,"title":3},"372":{"body":33,"breadcrumbs":6,"title":2},"373":{"body":37,"breadcrumbs":6,"title":2},"374":{"body":39,"breadcrumbs":6,"title":2},"375":{"body":28,"breadcrumbs":9,"title":5},"376":{"body":128,"breadcrumbs":8,"title":3},"377":{"body":6,"breadcrumbs":7,"title":2},"378":{"body":178,"breadcrumbs":8,"title":3},"379":{"body":58,"breadcrumbs":10,"title":5},"38":{"body":17,"breadcrumbs":8,"title":3},"380":{"body":52,"breadcrumbs":10,"title":5},"381":{"body":94,"breadcrumbs":7,"title":2},"382":{"body":52,"breadcrumbs":7,"title":2},"383":{"body":51,"breadcrumbs":9,"title":4},"384":{"body":23,"breadcrumbs":6,"title":1},"385":{"body":126,"breadcrumbs":8,"title":3},"386":{"body":29,"breadcrumbs":11,"title":6},"387":{"body":0,"breadcrumbs":7,"title":2},"388":{"body":22,"breadcrumbs":10,"title":5},"389":{"body":62,"breadcrumbs":9,"title":4},"39":{"body":186,"breadcrumbs":6,"title":1},"390":{"body":76,"breadcrumbs":9,"title":4},"391":{"body":14,"breadcrumbs":13,"title":4},"392":{"body":20,"breadcrumbs":10,"title":1},"393":{"body":7,"breadcrumbs":12,"title":3},"394":{"body":82,"breadcrumbs":12,"title":3},"395":{"body":177,"breadcrumbs":11,"title":2},"396":{"body":134,"breadcrumbs":12,"title":3},"397":{"body":3,"breadcrumbs":7,"title":1},"398":{"body":158,"breadcrumbs":7,"title":1},"399":{"body":40,"breadcrumbs":7,"title":1},"4":{"body":29,"breadcrumbs":2,"title":1},"40":{"body":75,"breadcrumbs":7,"title":2},"400":{"body":51,"breadcrumbs":8,"title":2},"401":{"body":3,"breadcrumbs":8,"title":2},"402":{"body":16,"breadcrumbs":7,"title":1},"403":{"body":9,"breadcrumbs":8,"title":2},"404":{"body":70,"breadcrumbs":10,"title":2},"405":{"body":150,"breadcrumbs":9,"title":1},"406":{"body":314,"breadcrumbs":11,"title":3},"407":{"body":38,"breadcrumbs":12,"title":4},"408":{"body":74,"breadcrumbs":12,"title":4},"409":{"body":41,"breadcrumbs":12,"title":4},"41":{"body":13,"breadcrumbs":6,"title":1},"410":{"body":0,"breadcrumbs":10,"title":2},"411":{"body":27,"breadcrumbs":13,"title":5},"412":{"body":19,"breadcrumbs":12,"title":4},"413":{"body":20,"breadcrumbs":13,"title":5},"414":{"body":24,"breadcrumbs":13,"title":5},"415":{"body":44,"breadcrumbs":13,"title":5},"416":{"body":64,"breadcrumbs":13,"title":5},"417":{"body":32,"breadcrumbs":14,"title":6},"418":{"body":75,"breadcrumbs":11,"title":3},"419":{"body":142,"breadcrumbs":12,"title":4},"42":{"body":36,"breadcrumbs":7,"title":2},"420":{"body":0,"breadcrumbs":9,"title":1},"421":{"body":18,"breadcrumbs":12,"title":4},"422":{"body":482,"breadcrumbs":10,"title":2},"423":{"body":101,"breadcrumbs":9,"title":1},"424":{"body":18,"breadcrumbs":9,"title":3},"425":{"body":80,"breadcrumbs":8,"title":2},"426":{"body":30,"breadcrumbs":8,"title":2},"427":{"body":7,"breadcrumbs":8,"title":1},"428":{"body":110,"breadcrumbs":10,"title":3},"429":{"body":279,"breadcrumbs":9,"title":2},"43":{"body":6,"breadcrumbs":8,"title":3},"430":{"body":10,"breadcrumbs":11,"title":3},"431":{"body":203,"breadcrumbs":9,"title":1},"432":{"body":116,"breadcrumbs":12,"title":4},"433":{"body":111,"breadcrumbs":11,"title":3},"434":{"body":6,"breadcrumbs":9,"title":3},"435":{"body":22,"breadcrumbs":8,"title":2},"436":{"body":16,"breadcrumbs":8,"title":2},"437":{"body":27,"breadcrumbs":11,"title":3},"438":{"body":0,"breadcrumbs":9,"title":1},"439":{"body":266,"breadcrumbs":14,"title":6},"44":{"body":8,"breadcrumbs":8,"title":3},"440":{"body":24,"breadcrumbs":12,"title":4},"441":{"body":35,"breadcrumbs":12,"title":5},"442":{"body":35,"breadcrumbs":10,"title":3},"443":{"body":51,"breadcrumbs":9,"title":2},"444":{"body":34,"breadcrumbs":11,"title":4},"445":{"body":53,"breadcrumbs":8,"title":1},"446":{"body":66,"breadcrumbs":9,"title":2},"447":{"body":57,"breadcrumbs":10,"title":3},"448":{"body":110,"breadcrumbs":8,"title":1},"449":{"body":115,"breadcrumbs":9,"title":2},"45":{"body":45,"breadcrumbs":8,"title":3},"450":{"body":75,"breadcrumbs":10,"title":3},"451":{"body":43,"breadcrumbs":11,"title":4},"452":{"body":106,"breadcrumbs":9,"title":2},"453":{"body":75,"breadcrumbs":10,"title":3},"454":{"body":66,"breadcrumbs":10,"title":3},"455":{"body":7,"breadcrumbs":8,"title":1},"456":{"body":130,"breadcrumbs":8,"title":1},"457":{"body":91,"breadcrumbs":11,"title":4},"458":{"body":6,"breadcrumbs":9,"title":3},"459":{"body":5,"breadcrumbs":8,"title":2},"46":{"body":64,"breadcrumbs":6,"title":1},"460":{"body":4,"breadcrumbs":8,"title":2},"461":{"body":8,"breadcrumbs":11,"title":3},"462":{"body":0,"breadcrumbs":10,"title":2},"463":{"body":25,"breadcrumbs":12,"title":4},"464":{"body":8,"breadcrumbs":12,"title":5},"465":{"body":20,"breadcrumbs":10,"title":3},"466":{"body":18,"breadcrumbs":10,"title":3},"467":{"body":12,"breadcrumbs":9,"title":3},"468":{"body":4,"breadcrumbs":8,"title":2},"469":{"body":2,"breadcrumbs":8,"title":2},"47":{"body":40,"breadcrumbs":6,"title":1},"470":{"body":2,"breadcrumbs":8,"title":2},"471":{"body":52,"breadcrumbs":12,"title":5},"472":{"body":0,"breadcrumbs":9,"title":2},"473":{"body":114,"breadcrumbs":8,"title":1},"474":{"body":174,"breadcrumbs":9,"title":2},"475":{"body":13,"breadcrumbs":9,"title":2},"476":{"body":32,"breadcrumbs":8,"title":1},"477":{"body":6,"breadcrumbs":8,"title":1},"478":{"body":77,"breadcrumbs":10,"title":3},"479":{"body":167,"breadcrumbs":9,"title":2},"48":{"body":205,"breadcrumbs":8,"title":3},"480":{"body":83,"breadcrumbs":9,"title":2},"481":{"body":39,"breadcrumbs":10,"title":3},"482":{"body":40,"breadcrumbs":9,"title":2},"483":{"body":72,"breadcrumbs":9,"title":2},"484":{"body":102,"breadcrumbs":8,"title":1},"485":{"body":0,"breadcrumbs":8,"title":1},"486":{"body":65,"breadcrumbs":11,"title":4},"487":{"body":59,"breadcrumbs":11,"title":4},"488":{"body":38,"breadcrumbs":10,"title":3},"489":{"body":54,"breadcrumbs":10,"title":3},"49":{"body":114,"breadcrumbs":8,"title":3},"490":{"body":70,"breadcrumbs":10,"title":3},"491":{"body":0,"breadcrumbs":10,"title":3},"492":{"body":85,"breadcrumbs":8,"title":1},"493":{"body":186,"breadcrumbs":9,"title":2},"494":{"body":180,"breadcrumbs":9,"title":2},"495":{"body":34,"breadcrumbs":11,"title":3},"496":{"body":15,"breadcrumbs":10,"title":2},"497":{"body":30,"breadcrumbs":12,"title":4},"498":{"body":40,"breadcrumbs":11,"title":3},"499":{"body":155,"breadcrumbs":11,"title":3},"5":{"body":40,"breadcrumbs":2,"title":1},"50":{"body":57,"breadcrumbs":8,"title":3},"500":{"body":33,"breadcrumbs":10,"title":2},"501":{"body":16,"breadcrumbs":10,"title":2},"502":{"body":45,"breadcrumbs":9,"title":1},"503":{"body":31,"breadcrumbs":9,"title":1},"504":{"body":13,"breadcrumbs":10,"title":2},"505":{"body":23,"breadcrumbs":11,"title":3},"506":{"body":6,"breadcrumbs":9,"title":1},"507":{"body":53,"breadcrumbs":9,"title":1},"508":{"body":53,"breadcrumbs":8,"title":1},"509":{"body":89,"breadcrumbs":8,"title":1},"51":{"body":24,"breadcrumbs":9,"title":4},"510":{"body":65,"breadcrumbs":8,"title":1},"511":{"body":149,"breadcrumbs":8,"title":1},"512":{"body":37,"breadcrumbs":8,"title":1},"513":{"body":11,"breadcrumbs":8,"title":1},"514":{"body":11,"breadcrumbs":8,"title":1},"515":{"body":11,"breadcrumbs":8,"title":1},"516":{"body":11,"breadcrumbs":8,"title":1},"517":{"body":0,"breadcrumbs":9,"title":2},"518":{"body":9,"breadcrumbs":8,"title":1},"519":{"body":28,"breadcrumbs":8,"title":1},"52":{"body":370,"breadcrumbs":6,"title":1},"520":{"body":7,"breadcrumbs":8,"title":1},"521":{"body":0,"breadcrumbs":8,"title":1},"522":{"body":58,"breadcrumbs":8,"title":1},"523":{"body":0,"breadcrumbs":8,"title":1},"524":{"body":56,"breadcrumbs":8,"title":1},"525":{"body":28,"breadcrumbs":8,"title":1},"526":{"body":15,"breadcrumbs":11,"title":4},"527":{"body":84,"breadcrumbs":8,"title":1},"528":{"body":7,"breadcrumbs":8,"title":1},"529":{"body":53,"breadcrumbs":8,"title":1},"53":{"body":146,"breadcrumbs":7,"title":2},"530":{"body":15,"breadcrumbs":5,"title":2},"531":{"body":49,"breadcrumbs":4,"title":1},"532":{"body":26,"breadcrumbs":5,"title":2},"533":{"body":25,"breadcrumbs":5,"title":2},"534":{"body":94,"breadcrumbs":5,"title":2},"535":{"body":37,"breadcrumbs":4,"title":1},"536":{"body":73,"breadcrumbs":7,"title":3},"537":{"body":83,"breadcrumbs":5,"title":1},"538":{"body":50,"breadcrumbs":5,"title":1},"539":{"body":77,"breadcrumbs":8,"title":4},"54":{"body":70,"breadcrumbs":9,"title":4},"540":{"body":50,"breadcrumbs":6,"title":2},"541":{"body":146,"breadcrumbs":8,"title":4},"542":{"body":0,"breadcrumbs":6,"title":2},"543":{"body":80,"breadcrumbs":6,"title":2},"544":{"body":20,"breadcrumbs":7,"title":3},"545":{"body":188,"breadcrumbs":5,"title":1},"546":{"body":65,"breadcrumbs":5,"title":1},"547":{"body":90,"breadcrumbs":5,"title":1},"548":{"body":85,"breadcrumbs":5,"title":1},"549":{"body":54,"breadcrumbs":5,"title":1},"55":{"body":25,"breadcrumbs":10,"title":5},"550":{"body":23,"breadcrumbs":5,"title":1},"551":{"body":39,"breadcrumbs":6,"title":2},"552":{"body":72,"breadcrumbs":7,"title":3},"553":{"body":86,"breadcrumbs":8,"title":4},"554":{"body":26,"breadcrumbs":5,"title":1},"555":{"body":146,"breadcrumbs":5,"title":1},"556":{"body":12,"breadcrumbs":6,"title":2},"557":{"body":12,"breadcrumbs":6,"title":2},"558":{"body":12,"breadcrumbs":6,"title":2},"559":{"body":12,"breadcrumbs":7,"title":3},"56":{"body":17,"breadcrumbs":8,"title":3},"560":{"body":12,"breadcrumbs":7,"title":3},"561":{"body":12,"breadcrumbs":7,"title":3},"562":{"body":17,"breadcrumbs":6,"title":2},"563":{"body":16,"breadcrumbs":6,"title":2},"564":{"body":47,"breadcrumbs":5,"title":1},"565":{"body":0,"breadcrumbs":6,"title":2},"566":{"body":25,"breadcrumbs":7,"title":3},"567":{"body":37,"breadcrumbs":6,"title":2},"568":{"body":17,"breadcrumbs":6,"title":2},"569":{"body":48,"breadcrumbs":6,"title":3},"57":{"body":19,"breadcrumbs":9,"title":4},"570":{"body":73,"breadcrumbs":4,"title":1},"571":{"body":194,"breadcrumbs":6,"title":3},"572":{"body":113,"breadcrumbs":5,"title":2},"573":{"body":0,"breadcrumbs":7,"title":4},"574":{"body":356,"breadcrumbs":4,"title":1},"575":{"body":393,"breadcrumbs":4,"title":1},"576":{"body":21,"breadcrumbs":5,"title":2},"577":{"body":7,"breadcrumbs":6,"title":3},"578":{"body":9,"breadcrumbs":8,"title":5},"579":{"body":125,"breadcrumbs":5,"title":2},"58":{"body":134,"breadcrumbs":9,"title":4},"580":{"body":63,"breadcrumbs":5,"title":2},"581":{"body":165,"breadcrumbs":3,"title":1},"582":{"body":78,"breadcrumbs":3,"title":1},"583":{"body":142,"breadcrumbs":6,"title":2},"584":{"body":69,"breadcrumbs":6,"title":2},"585":{"body":45,"breadcrumbs":7,"title":3},"586":{"body":0,"breadcrumbs":6,"title":2},"587":{"body":46,"breadcrumbs":9,"title":5},"588":{"body":50,"breadcrumbs":4,"title":1},"589":{"body":6,"breadcrumbs":4,"title":1},"59":{"body":92,"breadcrumbs":8,"title":3},"590":{"body":37,"breadcrumbs":5,"title":2},"591":{"body":121,"breadcrumbs":5,"title":2},"592":{"body":0,"breadcrumbs":5,"title":2},"593":{"body":43,"breadcrumbs":5,"title":2},"594":{"body":77,"breadcrumbs":5,"title":2},"595":{"body":41,"breadcrumbs":5,"title":2},"596":{"body":30,"breadcrumbs":5,"title":2},"597":{"body":21,"breadcrumbs":5,"title":2},"598":{"body":59,"breadcrumbs":6,"title":3},"599":{"body":25,"breadcrumbs":5,"title":2},"6":{"body":0,"breadcrumbs":2,"title":1},"60":{"body":121,"breadcrumbs":7,"title":2},"600":{"body":84,"breadcrumbs":5,"title":2},"601":{"body":28,"breadcrumbs":7,"title":4},"602":{"body":64,"breadcrumbs":7,"title":4},"603":{"body":15,"breadcrumbs":5,"title":2},"604":{"body":62,"breadcrumbs":5,"title":2},"605":{"body":67,"breadcrumbs":5,"title":2},"606":{"body":0,"breadcrumbs":5,"title":2},"607":{"body":27,"breadcrumbs":5,"title":2},"608":{"body":20,"breadcrumbs":5,"title":2},"609":{"body":118,"breadcrumbs":4,"title":1},"61":{"body":35,"breadcrumbs":6,"title":1},"610":{"body":25,"breadcrumbs":4,"title":1},"611":{"body":141,"breadcrumbs":4,"title":1},"612":{"body":67,"breadcrumbs":6,"title":3},"613":{"body":50,"breadcrumbs":5,"title":2},"614":{"body":175,"breadcrumbs":5,"title":2},"615":{"body":31,"breadcrumbs":5,"title":2},"616":{"body":11,"breadcrumbs":5,"title":2},"617":{"body":45,"breadcrumbs":4,"title":1},"618":{"body":9,"breadcrumbs":5,"title":2},"619":{"body":21,"breadcrumbs":5,"title":2},"62":{"body":132,"breadcrumbs":6,"title":1},"620":{"body":20,"breadcrumbs":5,"title":2},"621":{"body":17,"breadcrumbs":5,"title":2},"622":{"body":26,"breadcrumbs":9,"title":6},"623":{"body":464,"breadcrumbs":4,"title":1},"624":{"body":4,"breadcrumbs":4,"title":1},"625":{"body":31,"breadcrumbs":4,"title":1},"626":{"body":71,"breadcrumbs":4,"title":1},"627":{"body":85,"breadcrumbs":4,"title":1},"628":{"body":25,"breadcrumbs":4,"title":1},"629":{"body":49,"breadcrumbs":5,"title":2},"63":{"body":8,"breadcrumbs":7,"title":2},"630":{"body":4,"breadcrumbs":4,"title":1},"631":{"body":25,"breadcrumbs":4,"title":1},"632":{"body":6,"breadcrumbs":4,"title":1},"633":{"body":108,"breadcrumbs":5,"title":2},"634":{"body":113,"breadcrumbs":5,"title":2},"635":{"body":17,"breadcrumbs":5,"title":2},"636":{"body":34,"breadcrumbs":4,"title":1},"637":{"body":4,"breadcrumbs":4,"title":1},"638":{"body":34,"breadcrumbs":4,"title":1},"639":{"body":19,"breadcrumbs":4,"title":1},"64":{"body":17,"breadcrumbs":6,"title":1},"640":{"body":128,"breadcrumbs":4,"title":1},"641":{"body":34,"breadcrumbs":4,"title":1},"642":{"body":4,"breadcrumbs":4,"title":1},"643":{"body":110,"breadcrumbs":4,"title":1},"644":{"body":57,"breadcrumbs":4,"title":1},"645":{"body":53,"breadcrumbs":5,"title":2},"646":{"body":4,"breadcrumbs":4,"title":1},"647":{"body":19,"breadcrumbs":4,"title":1},"648":{"body":111,"breadcrumbs":4,"title":1},"649":{"body":40,"breadcrumbs":4,"title":1},"65":{"body":133,"breadcrumbs":6,"title":1},"650":{"body":83,"breadcrumbs":4,"title":1},"651":{"body":209,"breadcrumbs":4,"title":1},"652":{"body":1,"breadcrumbs":5,"title":2},"653":{"body":29,"breadcrumbs":4,"title":1},"654":{"body":39,"breadcrumbs":5,"title":2},"655":{"body":28,"breadcrumbs":5,"title":2},"656":{"body":21,"breadcrumbs":5,"title":2},"657":{"body":336,"breadcrumbs":5,"title":2},"658":{"body":25,"breadcrumbs":4,"title":1},"659":{"body":0,"breadcrumbs":5,"title":2},"66":{"body":81,"breadcrumbs":7,"title":2},"660":{"body":33,"breadcrumbs":7,"title":4},"661":{"body":31,"breadcrumbs":4,"title":1},"662":{"body":106,"breadcrumbs":5,"title":2},"663":{"body":78,"breadcrumbs":6,"title":3},"664":{"body":326,"breadcrumbs":4,"title":1},"665":{"body":26,"breadcrumbs":5,"title":2},"666":{"body":0,"breadcrumbs":5,"title":2},"667":{"body":113,"breadcrumbs":8,"title":5},"668":{"body":38,"breadcrumbs":5,"title":2},"669":{"body":58,"breadcrumbs":7,"title":2},"67":{"body":60,"breadcrumbs":8,"title":3},"670":{"body":1,"breadcrumbs":7,"title":2},"671":{"body":21,"breadcrumbs":6,"title":2},"672":{"body":36,"breadcrumbs":6,"title":2},"673":{"body":1,"breadcrumbs":6,"title":2},"674":{"body":102,"breadcrumbs":6,"title":3},"675":{"body":27,"breadcrumbs":5,"title":2},"676":{"body":36,"breadcrumbs":7,"title":4},"677":{"body":71,"breadcrumbs":6,"title":3},"678":{"body":1,"breadcrumbs":5,"title":2},"679":{"body":21,"breadcrumbs":6,"title":2},"68":{"body":54,"breadcrumbs":8,"title":3},"680":{"body":29,"breadcrumbs":5,"title":1},"681":{"body":0,"breadcrumbs":6,"title":2},"682":{"body":98,"breadcrumbs":5,"title":1},"683":{"body":54,"breadcrumbs":5,"title":1},"684":{"body":54,"breadcrumbs":5,"title":1},"685":{"body":83,"breadcrumbs":5,"title":1},"686":{"body":60,"breadcrumbs":5,"title":1},"687":{"body":0,"breadcrumbs":6,"title":2},"688":{"body":94,"breadcrumbs":7,"title":3},"689":{"body":156,"breadcrumbs":6,"title":2},"69":{"body":97,"breadcrumbs":8,"title":3},"690":{"body":58,"breadcrumbs":5,"title":2},"691":{"body":40,"breadcrumbs":5,"title":2},"692":{"body":53,"breadcrumbs":7,"title":4},"693":{"body":33,"breadcrumbs":6,"title":3},"694":{"body":8,"breadcrumbs":4,"title":1},"695":{"body":0,"breadcrumbs":4,"title":1},"696":{"body":105,"breadcrumbs":4,"title":1},"697":{"body":0,"breadcrumbs":4,"title":1},"698":{"body":136,"breadcrumbs":4,"title":1},"699":{"body":19,"breadcrumbs":4,"title":1},"7":{"body":47,"breadcrumbs":3,"title":2},"70":{"body":0,"breadcrumbs":7,"title":2},"700":{"body":0,"breadcrumbs":4,"title":1},"701":{"body":271,"breadcrumbs":5,"title":2},"702":{"body":0,"breadcrumbs":5,"title":2},"703":{"body":28,"breadcrumbs":5,"title":2},"704":{"body":76,"breadcrumbs":6,"title":2},"705":{"body":105,"breadcrumbs":6,"title":2},"706":{"body":70,"breadcrumbs":8,"title":4},"707":{"body":0,"breadcrumbs":6,"title":2},"708":{"body":43,"breadcrumbs":7,"title":3},"709":{"body":79,"breadcrumbs":7,"title":3},"71":{"body":79,"breadcrumbs":9,"title":4},"710":{"body":10,"breadcrumbs":5,"title":1},"711":{"body":10,"breadcrumbs":5,"title":1},"712":{"body":35,"breadcrumbs":5,"title":1},"713":{"body":106,"breadcrumbs":5,"title":1},"714":{"body":92,"breadcrumbs":6,"title":2},"715":{"body":0,"breadcrumbs":5,"title":1},"716":{"body":22,"breadcrumbs":7,"title":3},"717":{"body":98,"breadcrumbs":6,"title":2},"718":{"body":0,"breadcrumbs":6,"title":2},"719":{"body":92,"breadcrumbs":8,"title":4},"72":{"body":25,"breadcrumbs":11,"title":6},"720":{"body":30,"breadcrumbs":7,"title":3},"721":{"body":50,"breadcrumbs":7,"title":3},"722":{"body":22,"breadcrumbs":7,"title":3},"723":{"body":31,"breadcrumbs":7,"title":3},"724":{"body":15,"breadcrumbs":5,"title":2},"725":{"body":43,"breadcrumbs":4,"title":1},"726":{"body":147,"breadcrumbs":7,"title":4},"727":{"body":58,"breadcrumbs":5,"title":2},"728":{"body":27,"breadcrumbs":5,"title":2},"729":{"body":67,"breadcrumbs":5,"title":2},"73":{"body":63,"breadcrumbs":10,"title":5},"730":{"body":49,"breadcrumbs":4,"title":1},"731":{"body":161,"breadcrumbs":2,"title":1},"732":{"body":0,"breadcrumbs":3,"title":2},"733":{"body":9,"breadcrumbs":4,"title":3},"734":{"body":12,"breadcrumbs":4,"title":3},"735":{"body":62,"breadcrumbs":2,"title":1},"736":{"body":12,"breadcrumbs":2,"title":1},"737":{"body":34,"breadcrumbs":4,"title":3},"738":{"body":38,"breadcrumbs":4,"title":3},"739":{"body":13,"breadcrumbs":4,"title":3},"74":{"body":17,"breadcrumbs":11,"title":4},"740":{"body":27,"breadcrumbs":4,"title":3},"741":{"body":27,"breadcrumbs":4,"title":3},"742":{"body":45,"breadcrumbs":2,"title":1},"743":{"body":19,"breadcrumbs":3,"title":2},"744":{"body":34,"breadcrumbs":4,"title":3},"745":{"body":57,"breadcrumbs":4,"title":3},"746":{"body":33,"breadcrumbs":2,"title":1},"747":{"body":31,"breadcrumbs":2,"title":1},"748":{"body":50,"breadcrumbs":3,"title":2},"749":{"body":36,"breadcrumbs":3,"title":2},"75":{"body":122,"breadcrumbs":8,"title":1},"750":{"body":9,"breadcrumbs":3,"title":2},"751":{"body":80,"breadcrumbs":2,"title":1},"752":{"body":34,"breadcrumbs":3,"title":2},"753":{"body":41,"breadcrumbs":5,"title":4},"754":{"body":21,"breadcrumbs":4,"title":3},"755":{"body":20,"breadcrumbs":3,"title":2},"756":{"body":9,"breadcrumbs":3,"title":2},"757":{"body":15,"breadcrumbs":2,"title":1},"758":{"body":21,"breadcrumbs":4,"title":3},"759":{"body":46,"breadcrumbs":3,"title":2},"76":{"body":41,"breadcrumbs":9,"title":2},"760":{"body":53,"breadcrumbs":2,"title":1},"761":{"body":10,"breadcrumbs":2,"title":1},"762":{"body":30,"breadcrumbs":3,"title":2},"763":{"body":0,"breadcrumbs":3,"title":2},"764":{"body":48,"breadcrumbs":3,"title":2},"765":{"body":36,"breadcrumbs":4,"title":3},"766":{"body":54,"breadcrumbs":3,"title":2},"767":{"body":77,"breadcrumbs":2,"title":1},"768":{"body":22,"breadcrumbs":3,"title":2},"769":{"body":40,"breadcrumbs":2,"title":1},"77":{"body":18,"breadcrumbs":9,"title":2},"770":{"body":50,"breadcrumbs":3,"title":2},"771":{"body":105,"breadcrumbs":4,"title":3},"772":{"body":97,"breadcrumbs":3,"title":2},"773":{"body":0,"breadcrumbs":5,"title":4},"774":{"body":36,"breadcrumbs":2,"title":1},"775":{"body":20,"breadcrumbs":4,"title":3},"776":{"body":38,"breadcrumbs":4,"title":3},"777":{"body":29,"breadcrumbs":3,"title":2},"778":{"body":45,"breadcrumbs":3,"title":2},"779":{"body":121,"breadcrumbs":4,"title":3},"78":{"body":294,"breadcrumbs":10,"title":3},"780":{"body":21,"breadcrumbs":4,"title":3},"781":{"body":18,"breadcrumbs":4,"title":3},"782":{"body":10,"breadcrumbs":4,"title":3},"783":{"body":25,"breadcrumbs":4,"title":3},"784":{"body":10,"breadcrumbs":4,"title":3},"785":{"body":49,"breadcrumbs":4,"title":3},"786":{"body":21,"breadcrumbs":4,"title":3},"787":{"body":0,"breadcrumbs":4,"title":3},"788":{"body":17,"breadcrumbs":3,"title":2},"789":{"body":91,"breadcrumbs":3,"title":2},"79":{"body":79,"breadcrumbs":11,"title":4},"790":{"body":26,"breadcrumbs":3,"title":2},"791":{"body":22,"breadcrumbs":5,"title":4},"792":{"body":14,"breadcrumbs":4,"title":3},"793":{"body":7,"breadcrumbs":5,"title":4},"794":{"body":46,"breadcrumbs":2,"title":1},"795":{"body":14,"breadcrumbs":3,"title":2},"796":{"body":32,"breadcrumbs":3,"title":2},"797":{"body":36,"breadcrumbs":3,"title":2},"798":{"body":21,"breadcrumbs":3,"title":2},"799":{"body":0,"breadcrumbs":4,"title":3},"8":{"body":51,"breadcrumbs":3,"title":2},"80":{"body":79,"breadcrumbs":10,"title":3},"800":{"body":71,"breadcrumbs":3,"title":2},"81":{"body":23,"breadcrumbs":10,"title":5},"82":{"body":74,"breadcrumbs":6,"title":1},"83":{"body":36,"breadcrumbs":9,"title":4},"84":{"body":112,"breadcrumbs":7,"title":2},"85":{"body":128,"breadcrumbs":9,"title":4},"86":{"body":153,"breadcrumbs":10,"title":5},"87":{"body":17,"breadcrumbs":6,"title":1},"88":{"body":0,"breadcrumbs":7,"title":2},"89":{"body":36,"breadcrumbs":7,"title":2},"9":{"body":27,"breadcrumbs":3,"title":2},"90":{"body":81,"breadcrumbs":9,"title":3},"91":{"body":29,"breadcrumbs":8,"title":2},"92":{"body":34,"breadcrumbs":9,"title":3},"93":{"body":54,"breadcrumbs":9,"title":3},"94":{"body":16,"breadcrumbs":7,"title":1},"95":{"body":56,"breadcrumbs":8,"title":2},"96":{"body":22,"breadcrumbs":11,"title":5},"97":{"body":19,"breadcrumbs":11,"title":5},"98":{"body":419,"breadcrumbs":12,"title":6},"99":{"body":0,"breadcrumbs":8,"title":2}},"docs":{"0":{"body":"Table of Contents About Optimism About the OP Stack Site Navigation","breadcrumbs":"Introduction » OP Stack Specification","id":"0","title":"OP Stack Specification"},"1":{"body":"Optimism is a project dedicated to scaling Ethereum's technology and expanding its ability to coordinate people from across the world to build effective decentralized economies and governance systems. The Optimism Collective builds open-source software that powers scalable blockchains and aims to address key governance and economic challenges in the wider Ethereum ecosystem. Optimism operates on the principle of impact=profit , the idea that individuals who positively impact the Collective should be proportionally rewarded with profit. Change the incentives and you change the world.","breadcrumbs":"Introduction » About Optimism","id":"1","title":"About Optimism"},"10":{"body":"We strive to preserve three critical properties: liveness, validity, and availability. A protocol that can maintain these properties can, effectively, scale Ethereum without sacrificing security.","breadcrumbs":"Background » Protocol Guarantees","id":"10","title":"Protocol Guarantees"},"100":{"body":"This updates which L2 blocks the engine considers to be canonical (forkchoiceState argument), and optionally initiates block production (payloadAttributes argument). Within the rollup, the types of forkchoice updates translate as: headBlockHash: block hash of the head of the canonical chain. Labeled \"unsafe\" in user JSON-RPC. Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts. safeBlockHash: block hash of the canonical chain, derived from L1 data, unlikely to reorg. finalizedBlockHash: irreversible block hash, matches lower boundary of the dispute period. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV2 : the extended PayloadAttributesV2 Extended PayloadAttributesV2 PayloadAttributesV2 is extended to: PayloadAttributesV2: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The type notation used here refers to the HEX value encoding used by the Ethereum JSON-RPC API specification , as this structure will need to be sent over JSON-RPC. array refers to a JSON array. Each item of the transactions array is a byte list encoding a transaction: TransactionType || TransactionPayload or LegacyTransaction, as defined in EIP-2718 . This is equivalent to the transactions field in ExecutionPayloadV2 The transactions field is optional: If empty or missing: no changes to engine behavior. The sequencers will (if enabled) build a block by consuming transactions from the transaction pool. If present and non-empty: the payload MUST be produced starting with this exact list of transactions. The rollup driver determines the transaction list based on deterministic L1 inputs. The noTxPool is optional as well, and extends the transactions meaning: If false, the execution engine is free to pack additional transactions from external sources like the tx pool into the payload, after any of the transactions. This is the default behavior a L1 node implements. If true, the execution engine must not change anything about the given list of transactions. If the transactions field is present, the engine must execute the transactions in order and return STATUS_INVALID if there is an error processing the transactions. It must return STATUS_VALID if all of the transactions could be executed without error. Note : The state transition rules have been modified such that deposits will never fail so if engine_forkchoiceUpdatedV2 returns STATUS_INVALID it is because a batched transaction is invalid. The gasLimit is optional w.r.t. compatibility with L1, but required when used as rollup. This field overrides the gas limit used during block-building. If not specified as rollup, a STATUS_INVALID is returned.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV2","id":"100","title":"engine_forkchoiceUpdatedV2"},"101":{"body":"See engine_forkchoiceUpdatedV2 for a description of the forkchoice updated method. engine_forkchoiceUpdatedV3 must only be called with Ecotone payload. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV3 : the extended PayloadAttributesV3 Extended PayloadAttributesV3 PayloadAttributesV3 is extended to: PayloadAttributesV3: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 parentBeaconBlockRoot: DATA (32 bytes) transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The requirements of this object are the same as extended PayloadAttributesV2 with the addition of parentBeaconBlockRoot which is the parent beacon block root from the L1 origin block of the L2 block. Starting at Ecotone, the parentBeaconBlockRoot must be set to the L1 origin parentBeaconBlockRoot, or a zero bytes32 if the Dencun functionality with parentBeaconBlockRoot is not active on L1.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV3","id":"101","title":"engine_forkchoiceUpdatedV3"},"102":{"body":"No modifications to engine_newPayloadV2 . Applies a L2 block to the engine state.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV2","id":"102","title":"engine_newPayloadV2"},"103":{"body":"engine_newPayloadV3 applies an Ecotone L2 block to the engine state. There are no modifications to this API. engine_newPayloadV3 must only be called with Ecotone payload. The additional parameters should be set as follows: expectedBlobVersionedHashes MUST be an empty array. parentBeaconBlockRoot MUST be the parent beacon block root from the L1 origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV3","id":"103","title":"engine_newPayloadV3"},"104":{"body":"No modifications to engine_getPayloadV2 . Retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV2 when called with payloadAttributes.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV2","id":"104","title":"engine_getPayloadV2"},"105":{"body":"engine_getPayloadV3 retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV3 when called with payloadAttributes. engine_getPayloadV3 must only be called with Ecotone payload. Extended Response The response is extended to: { executionPayload: ExecutionPayload blockValue: QUANTITY blobsBundle: BlobsBundle shouldOverrideBuilder: BOOLEAN parentBeaconBlockRoot: DATA (32 bytes)\n} In Ecotone it MUST be set to the parentBeaconBlockRoot from the L1 Origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV3","id":"105","title":"engine_getPayloadV3"},"106":{"body":"Optional extension to the Engine API. Signals superchain information to the Engine: V1 signals which protocol version is recommended and required. Types: SuperchainSignal: { recommended: ProtocolVersion; required: ProtocolVersion;\n} ProtocolVersion: encoded for RPC as defined in Protocol Version format specification . Parameters: signal: SuperchainSignal, the signaled superchain information. Returns: ProtocolVersion: the latest supported OP-Stack protocol version of the execution engine. The execution engine SHOULD warn the user when the recommended version is newer than the current version supported by the execution engine. The execution engine SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the execution engine operator.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_signalSuperchainV1","id":"106","title":"engine_signalSuperchainV1"},"107":{"body":"The execution engine can acquire all data through the rollup node, as derived from L1: P2P networking is strictly optional. However, to not bottleneck on L1 data retrieval speed, the P2P network functionality SHOULD be enabled, serving: Peer discovery ( Disc v5 ) eth/66 : Transaction pool (consumed by sequencer nodes) State sync (happy-path for fast trustless db replication) Historical block header and body retrieval New blocks are acquired through the consensus layer instead (rollup node) No modifications to L1 network functionality are required, except configuration: networkID : Distinguishes the L2 network from L1 and testnets. Equal to the chainID of the rollup network. Activate Merge fork: Enables Engine API and disables propagation of blocks, as block headers cannot be authenticated without consensus layer. Bootnode list: DiscV5 is a shared network, bootstrap is faster through connecting with L2 nodes first.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Networking","id":"107","title":"Networking"},"108":{"body":"The execution engine can operate sync in different ways: Happy-path: rollup node informs engine of the desired chain head as determined by L1, completes through engine P2P. Worst-case: rollup node detects stalled engine, completes sync purely from L1 data, no peers required. The happy-path is more suitable to bring new nodes online quickly, as the engine implementation can sync state faster through methods like snap-sync .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Sync","id":"108","title":"Sync"},"109":{"body":"The rollup node informs the engine of the L2 chain head, unconditionally (part of regular node operation): Bedrock / Canyon / Delta Payloads engine_newPayloadV2 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV2 is called with the current unsafe/safe/finalized L2 block hashes. Ecotone Payloads engine_newPayloadV3 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV3 is called with the current unsafe/safe/finalized L2 block hashes. The engine requests headers from peers, in reverse till the parent hash matches the local chain The engine catches up: a) A form of state sync is activated towards the finalized or head block hash b) A form of block sync pulls block bodies and processes towards head block hash The exact P2P based sync is out of scope for the L2 specification: the operation within the engine is the exact same as with L1 (although with an EVM that supports deposits).","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Happy-path sync","id":"109","title":"Happy-path sync"},"11":{"body":"Liveness is defined as the ability for any party to be able to extend the rollup chain by including a transaction within a bounded amount of time. It should not be possible for an actor to block the inclusion of any given transaction for more than this bounded time period. This bounded time period should also be acceptable such that inclusion is not just theoretically possible but practically useful.","breadcrumbs":"Background » Liveness","id":"11","title":"Liveness"},"110":{"body":"Engine is out of sync, not peered and/or stalled due other reasons. The rollup node maintains latest head from engine (poll eth_getBlockByNumber and/or maintain a header subscription) The rollup node activates sync if the engine is out of sync but not syncing through P2P (eth_syncing) The rollup node inserts blocks, derived from L1, one by one, potentially adapting to L1 reorg(s), as outlined in the rollup node spec .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Worst-case sync","id":"110","title":"Worst-case sync"},"111":{"body":"EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction, plus a list of \"blobs\": \"Binary Large Object\", i.e. a dedicated data type for serving Data-Availability as base-layer. With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception: as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type. EIP-4844 is disabled as following: Transaction network-layer announcements, announcing blob-type transactions, are ignored. Transactions of the blob-type, through the RPC or otherwise, are not allowed into the transaction pool. Block-building code does not select EIP-4844 transactions. An L2 block state-transition with EIP-4844 transactions is invalid. The BLOBBASEFEE opcode is present but its semantics are altered because there are no blobs processed by L2. The opcode will always push a value of 1 onto the stack.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: disable Blob-transactions","id":"111","title":"Ecotone: disable Blob-transactions"},"112":{"body":"EIP-4788 introduces a \"beacon block root\" into the execution-layer block-header and EVM. This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block. With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO of L1. And thus with EIP-4788 the L1 beacon block root is made available. For the Ecotone upgrade, this entails that: The parent_beacon_block_root of the L1 origin is now embedded in the L2 block header. The \"Beacon roots contract\" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis. The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: Beacon Block Root","id":"112","title":"Ecotone: Beacon Block Root"},"113":{"body":"The Ethereum Node Record (ENR) for an Optimism execution node must contain an opel key-value pair where the key is opel and the value is a EIP-2124 fork id. The EL uses a different key from the CL in order to stop EL and CL nodes from connecting to each other.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » P2P Modifications","id":"113","title":"P2P Modifications"},"114":{"body":"Table of Contents Overview Driver Derivation L2 Output RPC method Structures BlockID L1BlockRef L2BlockRef SyncStatus Output Method API Protocol Version tracking","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node Specification","id":"114","title":"Rollup Node Specification"},"115":{"body":"The rollup node is the component responsible for deriving the L2 chain from L1 blocks (and their associated receipts ). The part of the rollup node that derives the L2 chain is called the rollup driver . This document is currently only concerned with the specification of the rollup driver.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Overview","id":"115","title":"Overview"},"116":{"body":"The task of the driver in the rollup node is to manage the derivation process: Keep track of L1 head block Keep track of the L2 chain sync progress Iterate over the derivation steps as new inputs become available","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Driver","id":"116","title":"Driver"},"117":{"body":"This process happens in three steps: Select inputs from the L1 chain, on top of the last L2 block: a list of blocks, with transactions and associated data and receipts. Read L1 information, deposits, and sequencing batches in order to generate payload attributes (essentially a block without output properties ). Pass the payload attributes to the execution engine , so that the L2 block (including output block properties ) may be computed. While this process is conceptually a pure function from the L1 chain to the L2 chain, it is in practice incremental. The L2 chain is extended whenever new L1 blocks are added to the L1 chain. Similarly, the L2 chain re-organizes whenever the L1 chain re-organizes . For a complete specification of the L2 block derivation, refer to the L2 block derivation document .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation","id":"117","title":"Derivation"},"118":{"body":"The Rollup node has its own RPC method, optimism_outputAtBlock which returns a 32 byte hash corresponding to the L2 output root .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » L2 Output RPC method","id":"118","title":"L2 Output RPC method"},"119":{"body":"These define the types used by rollup node API methods. The types defined here are extended from the engine API specs . BlockID hash: DATA, 32 Bytes number: QUANTITY, 64 Bits L1BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits L2BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits l1origin: BlockID sequenceNumber: QUANTITY, 64 Bits - distance to first block of epoch SyncStatus Represents a snapshot of the rollup driver. current_l1: Object - instance of L1BlockRef . current_l1_finalized: Object - instance of L1BlockRef . head_l1: Object - instance of L1BlockRef . safe_l1: Object - instance of L1BlockRef . finalized_l1: Object - instance of L1BlockRef . unsafe_l2: Object - instance of L2BlockRef . safe_l2: Object - instance of L2BlockRef . finalized_l2: Object - instance of L2BlockRef . pending_safe_l2: Object - instance of L2BlockRef . queued_unsafe_l2: Object - instance of L2BlockRef .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Structures","id":"119","title":"Structures"},"12":{"body":"Validity is defined as the ability for any party to execute the rollup state transition function, subject to certain lower bound expectations for available computing and bandwidth resources. Validity is also extended to refer to the ability for a smart contract on Ethereum to be able to validate this state transition function economically.","breadcrumbs":"Background » Validity","id":"12","title":"Validity"},"120":{"body":"The input and return types here are as defined by the engine API specs . method: optimism_outputAtBlock params: blockNumber: QUANTITY, 64 bits - L2 integer block number. returns: version: DATA, 32 Bytes - the output root version number, beginning with 0. outputRoot: DATA, 32 Bytes - the output root. blockRef: Object - instance of L2BlockRef . withdrawalStorageRoot: 32 bytes - storage root of the L2toL1MessagePasser contract. stateRoot: DATA: 32 bytes - the state root. syncStatus: Object - instance of SyncStatus .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Output Method API","id":"120","title":"Output Method API"},"121":{"body":"The rollup-node should monitor the recommended and required protocol version by monitoring the Protocol Version contract on L1, as specified in the Superchain Version Signaling specifications . This can be implemented through polling in the Driver loop. After polling the Protocol Version, the rollup node SHOULD communicate it with the execution-engine through an engine_signalSuperchainV1 call. The rollup node SHOULD warn the user when the recommended version is newer than the current version supported by the rollup node. The rollup node SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the rollup node operator.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Protocol Version tracking","id":"121","title":"Protocol Version tracking"},"122":{"body":"Table of Contents Overview P2P configuration Identification Discv5 Consensus Layer Structure LibP2P Transport Dialing NAT Peer management Transport security Protocol negotiation Identify Ping Multiplexing GossipSub Content-based message identification Message compression and limits Message ID computation Heartbeat and parameters Topic configuration Topic validation Gossip Topics blocksv1 blocksv2 blocksv3 Block encoding Block signatures Block validation Block processing Block topic scoring parameters Req-Resp payload_by_number","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Rollup-node P2P interface","id":"122","title":"Rollup-node P2P interface"},"123":{"body":"The rollup node has an optional peer-to-peer (P2P) network service to improve the latency between the view of sequencers and the rest of the network by bypassing the L1 in the happy case, without relying on a single centralized endpoint. This also enables faster historical sync to be bootstrapped by providing block headers to sync towards, and only having to compare the L2 chain inputs to the L1 data as compared to processing everything one block at a time. The rollup node will always prioritize L1 and reorganize to match the canonical chain. The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the \"unsafe\" chain, to improve the happy case performance. This also means that P2P behavior is a soft-rule: nodes keep each other in check with scoring and eventual banning of malicious peers by identity or IP. Any behavior on the P2P layer does not affect the rollup security, at worst nodes rely on higher-latency data from L1 to serve. In summary, the P2P stack looks like: Discovery to find peers: Discv5 Connections, peering, transport security, multiplexing, gossip: LibP2P Application-layer publishing and validation of gossiped messages like L2 blocks. This document only specifies the composition and configuration of these network libraries. These components have their own standards, implementations in Go/Rust/Java/Nim/JS/more, and are adopted by several other blockchains, most notably the L1 consensus layer (Eth2) .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Overview","id":"123","title":"Overview"},"124":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » P2P configuration","id":"124","title":"P2P configuration"},"125":{"body":"Nodes have a separate network- and consensus-identity. The network identity is a secp256k1 key, used for both discovery and active LibP2P connections. Common representations of network identity: PeerID: a LibP2P specific ID derived from the pubkey (through protobuf encoding, typing and hashing) NodeID: a Discv5 specific ID derived from the pubkey (through hashing, used in the DHT) Multi-address: an unsigned address, containing: IP, TCP port, PeerID ENR: a signed record used for discovery, containing: IP, TCP port, UDP port, signature (pubkey can be derived) and L2 network identification. Generally encoded in base64.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Identification","id":"125","title":"Identification"},"126":{"body":"Consensus Layer Structure The Ethereum Node Record (ENR) for an Optimism rollup node must contain the following values, identified by unique keys: An IPv4 address (ip field) and/or IPv6 address (ip6 field). A TCP port (tcp field) representing the local libp2p listening port. A UDP port (udp field) representing the local discv5 listening port. An OpStack (opstack field) L2 network identifier The opstack value is encoded as a single RLP bytes value, the concatenation of: chain ID (unsigned varint) fork ID (unsigned varint) Note that DiscV5 is a shared DHT (Distributed Hash Table): the L1 consensus and execution nodes, as well as testnet nodes, and even external IOT nodes, all communicate records in this large common DHT. This makes it more difficult to censor the discovery of node records. The discovery process in Optimism is a pipeline of node records: Fill the table with FINDNODES if necessary (Performed by Discv5 library) Pull additional records with searches to random Node IDs if necessary (e.g. iterate RandomNodes() in Go implementation) Pull records from the DiscV5 module when looking for peers Check if the record contains the opstack entry, verify it matches the chain ID and current or future fork number If not already connected, and not recently disconnected or put on deny-list, attempt to dial.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Discv5","id":"126","title":"Discv5"},"127":{"body":"Transport TCP transport. Additional transports are supported by LibP2P, but not required. Dialing Nodes should be publicly dialable, not rely on relay extensions, and able to dial both IPv4 and IPv6. NAT The listening endpoint must be publicly facing, but may be configured behind a NAT. LibP2P will use PMP / UPNP based techniques to track the external IP of the node. It is recommended to disable the above if the external IP is static and configured manually. Peer management The default is to maintain a peer count with a tide-system based on active peer count: At \"low tide\" the node starts to actively search for additional peer connections. At \"high tide\" the node starts to prune active connections, except those that are marked as trusted or have a grace period. Peers will have a grace period for a configurable amount of time after joining. In an emergency, when memory runs low, the node should start pruning more aggressively. Peer records can be persisted to disk to quickly reconnect with known peers after restarting the rollup node. The discovery process feeds the peerstore with peer records to connect to, tagged with a time-to-live (TTL). The current P2P processes do not require selective topic-specific peer connections, other than filtering for the basic network participation requirement. Peers may be banned if their performance score is too low, or if an objectively malicious action was detected. Banned peers will be persisted to the same data-store as the peerstore records. TODO: the connection gater does currently not gate by IP address on the dial Accept-callback. Transport security Libp2p-noise , XX handshake, with the secp256k1 P2P identity, as popularized in Eth2. The TLS option is available as well, but noise should be prioritized in negotiation. Protocol negotiation Multistream-select 1.0 (/multistream/1.0.0) is an interactive protocol used to negotiate sub-protocols supported in LibP2P peers. Multistream-select 2.0 may be used in the future. Identify LibP2P offers a minimal identification module to share client version and programming language. This is optional and can be disabled for enhanced privacy. It also includes the same protocol negotiation information, which can speed up initial connections. Ping LibP2P includes a simple ping protocol to track latency between connections. This should be enabled to help provide insight into the network health. Multiplexing For async communication over different channels over the same connection, multiplexing is used. mplex (/mplex/6.7.0) is required, and yamux (/yamux/1.0.0) is recommended but optional GossipSub GossipSub 1.1 (/meshsub/1.1.0, i.e. with peer-scoring extension) is a pubsub protocol for mesh-networks, deployed on L1 consensus (Eth2) and other protocols such as Filecoin, offering lots of customization options. Content-based message identification Messages are deduplicated, and filtered through application-layer signature verification. Thus origin-stamping is disabled and published messages must only contain application data, enforced through a StrictNoSign Signature Policy This provides greater privacy, and allows sequencers (consensus identity) to maintain multiple network identities for redundancy. Message compression and limits The application contents are compressed with snappy single-block-compression (as opposed to frame-compression), and constrained to 10 MiB. Message ID computation Same as L1 , with recognition of compression: If message.data has a valid snappy decompression, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_VALID_SNAPPY with the snappy decompressed message data, i.e. SHA256(MESSAGE_DOMAIN_VALID_SNAPPY + snappy_decompress(message.data))[:20]. Otherwise, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_INVALID_SNAPPY with the raw message data, i.e. SHA256(MESSAGE_DOMAIN_INVALID_SNAPPY + message.data)[:20]. Heartbeat and parameters GossipSub parameters : D (topic stable mesh target count): 8 D_low (topic stable mesh low watermark): 6 D_high (topic stable mesh high watermark): 12 D_lazy (gossip target): 6 heartbeat_interval (interval of heartbeat, in seconds): 0.5 fanout_ttl (ttl for fanout maps for topics we are not subscribed to but have published to, in seconds): 24 mcache_len (number of windows to retain full messages in cache for IWANT responses): 12 mcache_gossip (number of windows to gossip about): 3 seen_ttl (number of heartbeat intervals to retain message IDs): 130 (= 65 seconds) Notable differences from L1 consensus (Eth2): seen_ttl does not need to cover a full L1 epoch (6.4 minutes), but rather just a small window covering latest blocks fanout_ttl: adjusted to lower than seen_ttl mcache_len: a larger number of heartbeats can be retained since the gossip is much less noisy. heartbeat_interval: faster interval to reduce latency, bandwidth should still be reasonable since there are far fewer messages to gossip about each interval than on L1 which uses an interval of 0.7 seconds. Topic configuration Topics have string identifiers and are communicated with messages and subscriptions. /optimism/chain_id/hardfork_version/Name chain_id: replace with decimal representation of chain ID hardfork_version: replace with decimal representation of hardfork, starting at 0 Name: topic application-name Note that the topic encoding depends on the topic, unlike L1, since there are less topics, and all are snappy-compressed. Topic validation To ensure only valid messages are relayed, and malicious peers get scored based on application behavior, an extended validator checks the message before it is relayed or processed. The extended validator emits one of the following validation signals: ACCEPT valid, relayed to other peers and passed to local topic subscriber IGNORE scored like inactivity, message is dropped and not processed REJECT score penalties, message is dropped","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » LibP2P","id":"127","title":"LibP2P"},"128":{"body":"There are three topics for distributing blocks to other nodes faster than proxying through L1 would. These are:","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Gossip Topics","id":"128","title":"Gossip Topics"},"129":{"body":"Pre-Canyon/Shanghai blocks are broadcast on /optimism//0/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv1","id":"129","title":"blocksv1"},"13":{"body":"Availability is defined as the ability for any party to retrieve the inputs that are necessary to execute the rollup state transition function correctly. Availability is essentially an element of validity and is required to be able to guarantee validity in general. Similar to validity, availability is subject to lower bound resource requirements.","breadcrumbs":"Background » Availability","id":"13","title":"Availability"},"130":{"body":"Canyon/Delta blocks are broadcast on /optimism//1/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv2","id":"130","title":"blocksv2"},"131":{"body":"Ecotone blocks are broadcast on /optimism//2/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv3","id":"131","title":"blocksv3"},"132":{"body":"A block is structured as the concatenation of: V1 and V2 topics signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. V3 topic signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) parentBeaconBlockRoot: L1 origin parent beacon block root, always 32 bytes payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. All topics use Snappy block-compression (i.e. no snappy frames): the above needs to be compressed after encoding, and decompressed before decoding.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block encoding","id":"132","title":"Block encoding"},"133":{"body":"The signature is a secp256k1 signature, and signs over a message: keccak256(domain ++ chain_id ++ payload_hash), where: domain is 32 bytes, reserved for message types and versioning info. All zero for this signature. chain_id is a big-endian encoded uint256. payload_hash is keccak256(payload), where payload is the payload in V1 and V2, and parentBeaconBlockRoot ++ payload in V3. The secp256k1 signature must have y_parity = 1 or 0, the chain_id is already signed over.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block signatures","id":"133","title":"Block signatures"},"134":{"body":"An extended-validator checks the incoming messages as follows, in order of operation: [REJECT] if the compression is not valid [REJECT] if the block encoding is not valid [REJECT] if the payload.timestamp is older than 60 seconds in the past (graceful boundary for worst-case propagation and clock skew) [REJECT] if the payload.timestamp is more than 5 seconds into the future [REJECT] if the block_hash in the payload is not valid [REJECT] if the block is on the V1 topic and has withdrawals [REJECT] if the block is on the V1 topic and has a withdrawals list [REJECT] if the block is on a topic >= V2 and does not have an empty withdrawals list [REJECT] if the block is on a topic <= V2 and has a blob gas-used value set [REJECT] if the block is on a topic <= V2 and has an excess blob gas value set [REJECT] if the block is on a topic >= V3 and has a blob gas-used value that is not zero [REJECT] if the block is on a topic >= V3 and has an excess blob gas value that is not zero [REJECT] if the block is on a topic <= V2 and the parent beacon block root is not nil [REJECT] if the block is on a topic >= V3 and the parent beacon block root is nil [REJECT] if more than 5 different blocks have been seen with the same block height [IGNORE] if the block has already been seen [REJECT] if the signature by the sequencer is not valid Mark the block as seen for the given block height The block is signed by the corresponding sequencer, to filter malicious messages. The sequencer model is singular but may change to multiple sequencers in the future. A default sequencer pubkey is distributed with rollup nodes and should be configurable. Note that blocks that a block may still be propagated even if the L1 already confirmed a different block. The local L1 view of the node may be wrong, and the time and signature validation will prevent spam. Hence, calling into the execution engine with a block lookup every propagation step is not worth the added delay. Block processing A node may apply the block to their local engine ahead of L1 availability, if it ensures that: The application of the block is reversible, in case of a conflict with delayed L1 information The subsequent forkchoice-update ensures this block is recognized as \"unsafe\" (see fork choice updated ) Block topic scoring parameters TODO: GossipSub per-topic scoring to fine-tune incentives for ideal propagation delay and bandwidth usage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block validation","id":"134","title":"Block validation"},"135":{"body":"The op-node implements a similar request-response encoding for its sync protocols as the L1 ethereum Beacon-Chain. See L1 P2P-interface req-resp specification and Altair P2P update . However, the protocol is simplified, to avoid several issues seen in L1: Error strings in responses, if there is any alternative response, should not need to be compressed or have an artificial global length limit. Payload lengths should be fixed-length: byte-by-byte uvarint reading from the underlying stream is undesired. are relaxed to encode a uint32, rather than a beacon-chain ForkDigest. Payload-encoding may change per hardfork, so is not part of the protocol-ID. Usage of response-chunks is specific to the req-resp method: most basic req-resp does not need chunked responses. Compression is encouraged to be part of the payload-encoding, specific to the req-resp method, where necessary: pings and such do not need streaming frame compression etc. And the protocol ID format follows the same scheme as L1, except the trailing encoding schema part, which is now message-specific: /ProtocolPrefix/MessageName/SchemaVersion/ The req-resp protocols served by the op-node all have /ProtocolPrefix set to /opstack/req. Individual methods may include the chain ID as part of the /MessageName segment, so it's immediately clear which chain the method applies to, if the communication is chain-specific. Other methods may include chain-information in the request and/or response data, such as the ForkDigest in L1 beacon chain req-resp protocols. Each segment starts with a /, and may contain multiple /, and the final protocol ID is suffixed with a /.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Req-Resp","id":"135","title":"Req-Resp"},"136":{"body":"This is an optional chain syncing method, to request/serve execution payloads by number. This serves as a method to fill gaps upon missed gossip, and sync short to medium ranges of unsafe L2 blocks. Protocol ID: /opstack/req/payload_by_number//0/ /MessageName is /block_by_number/ where is set to the op-node L2 chain ID. /SchemaVersion is /0 Request format: : a little-endian uint64 - the block number to request. Response format: = is a byte code describing the result. 0 on success, should follow. 1 if valid request, but unavailable payload. 2 if invalid request 3+ if other error The >= 128 range is reserved for future use. is a little-endian uint32, identifying the response type (fork-specific) is an encoded block, read till stream EOF. The input of should be limited, as well as any generated decompressed output, to avoid unexpected resource usage or zip-bomb type attacks. A 10 MB limit is recommended, to ensure all blocks may be synced. Implementations may opt for a different limit, since this sync method is optional. list: 0: SSZ-encoded ExecutionPayload, with Snappy framing compression, matching the ExecutionPayload SSZ definition of the L1 Merge, L2 Bedrock and L2 Regolith, L2 Canyon versions. 1: SSZ-encoded ExecutionPayloadEnvelope with Snappy framing compression, matching the ExecutionPayloadEnvelope SSZ definition of the L2 Ecotone version. The request is by block-number, enabling parallel fetching of a chain across many peers. A res = 0 response should be verified to: Have a block-number matching the requested block number. Have a consistent blockhash w.r.t. the other block contents. Build towards a known canonical block. This can be verified by checking if the parent-hash of a previous trusted canonical block matches that of the verified hash of the retrieved block. For unsafe blocks this may be relaxed to verification against the parent-hash of any previously trusted block: The gossip validation process limits the amount of blocks that may be trusted to sync towards. The unsafe blocks should be queued for processing, the latest received L2 unsafe blocks should always override any previous chain, until the final L2 chain can be reproduced from L1 data. A res > 0 response code should not be accepted. The result code is helpful for debugging, but the client should regard any error like any other unanswered request, as the responding peer cannot be trusted.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » payload_by_number","id":"136","title":"payload_by_number"},"137":{"body":"Table of Contents Overview Eager Block Derivation Protocol Parameters Batch Submission Sequencing & Batch Submission Overview Batch Submission Wire Format Batcher Transaction Format Frame Format Channel Format Batch Format Architecture L2 Chain Derivation Pipeline L1 Traversal L1 Retrieval Frame Queue Channel Bank Pruning Timeouts Reading Loading frames Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue Engine API usage Bedrock, Canyon, Delta: API Usage Ecotone: API Usage Forkchoice synchronization L1-consolidation: payload attributes matching L1-sync: payload attributes processing Processing unsafe payload attributes Resetting the Pipeline Finding the sync starting point Resetting derivation stages About reorgs Post-Merge Deriving Payload Attributes Deriving the Transaction List Network upgrade automation transactions Ecotone L1Block Deployment GasPriceOracle Deployment L1Block Proxy Update GasPriceOracle Proxy Update GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) Building Individual Payload Attributes","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Specification","id":"137","title":"L2 Chain Derivation Specification"},"138":{"body":"Note the following assumes a single sequencer and batcher. In the future, the design will be adapted to accommodate multiple such entities. L2 chain derivation — deriving L2 blocks from L1 data — is one of the main responsibilities of the rollup node , both in validator mode, and in sequencer mode (where derivation acts as a sanity check on sequencing, and enables detecting L1 chain re-organizations ). The L2 chain is derived from the L1 chain. In particular, each L1 block following L2 chain inception is mapped to a sequencing epoch comprising at least one L2 block. Each L2 block belongs to exactly one epoch, and we call the corresponding L1 block its L1 origin . The epoch's number equals that of its L1 origin block. To derive the L2 blocks of epoch number E, we need the following inputs: L1 blocks in the range [E, E + SWS), called the sequencing window of the epoch, and SWS the sequencing window size. (Note that sequencing windows overlap.) Batcher transactions from blocks in the sequencing window. These transactions allow us to reconstruct the epoch's sequencer batches , each of which will produce one L2 block. Note that: The L1 origin will never contain any data needed to construct sequencer batches since each batch must contain the L1 origin hash. An epoch may have no sequencer batches. Deposits made in the L1 origin (in the form of events emitted by the deposit contract ). L1 block attributes from the L1 origin (to derive the L1 attributes deposited transaction ). The state of the L2 chain after the last L2 block of the previous epoch, or the L2 genesis state if E is the first epoch. To derive the whole L2 chain from scratch, we start with the L2 genesis state and the L2 genesis block as the first L2 block. We then derive L2 blocks from each epoch in order, starting at the first L1 block following L2 chain inception . Refer to the Architecture section for more information on how we implement this in practice. The L2 chain may contain pre-Bedrock history, but the L2 genesis here refers to the Bedrock L2 genesis block. Each L2 block with origin l1_origin is subject to the following constraints (whose values are denominated in seconds): block.timestamp = prev_l2_timestamp + l2_block_time prev_l2_timestamp is the timestamp of the L2 block immediately preceding this one. If there is no preceding block, then this is the genesis block, and its timestamp is explicitly specified. l2_block_time is a configurable parameter of the time between L2 blocks (2s on Optimism). l1_origin.timestamp <= block.timestamp <= max_l2_timestamp, where max_l2_timestamp = max(l1_origin.timestamp + max_sequencer_drift, prev_l2_timestamp + l2_block_time) max_sequencer_drift is a configurable parameter that bounds how far the sequencer can get ahead of the L1. Finally, each epoch must have at least one L2 block. The first constraint means there must be an L2 block every l2_block_time seconds following L2 chain inception. The second constraint ensures that an L2 block timestamp never precedes its L1 origin timestamp, and is never more than max_sequencer_drift ahead of it, except only in the unusual case where it might prohibit an L2 block from being produced every l2_block_time seconds. (Such cases might arise for example under a proof-of-work L1 that sees a period of rapid L1 block production.) In either case, the sequencer enforces len(batch.transactions) == 0 while max_sequencer_drift is exceeded. See Batch Queue for more details. The final requirement that each epoch must have at least one L2 block ensures that all relevant information from the L1 (e.g. deposits) is represented in the L2, even if it has no sequencer batches. Post-merge, Ethereum has a fixed 12s block time , though some slots can be skipped. Under a 2s L2 block time, we thus expect each epoch to typically contain 12/2 = 6 L2 blocks. The sequencer will however produce bigger epochs in order to maintain liveness in case of either a skipped slot on the L1 or a temporary loss of connection to it. For the lost connection case, smaller epochs might be produced after the connection was restored to keep L2 timestamps from drifting further and further ahead.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Overview","id":"138","title":"Overview"},"139":{"body":"Deriving an L2 block requires that we have constructed its sequencer batch and derived all L2 blocks and state updates prior to it. This means we can typically derive the L2 blocks of an epoch eagerly without waiting on the full sequencing window. The full sequencing window is required before derivation only in the very worst case where some portion of the sequencer batch for the first block of the epoch appears in the very last L1 block of the window. Note that this only applies to block derivation. Sequencer batches can still be derived and tentatively queued without deriving blocks from them.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Eager Block Derivation","id":"139","title":"Eager Block Derivation"},"14":{"body":"Generally speaking, there are three primary actors that interact with an OP Stack chain: users, sequencers, and verifiers. graph TD EthereumL1(Ethereum L1) subgraph \"L2 Participants\" Users(Users) Sequencers(Sequencers) Verifiers(Verifiers) end Verifiers -.->|fetch transaction batches| EthereumL1 Verifiers -.->|fetch deposit data| EthereumL1 Verifiers -->|submit/validate/challenge output proposals| EthereumL1 Verifiers -.->|fetch realtime P2P updates| Sequencers Users -->|submit deposits/withdrawals| EthereumL1 Users -->|submit transactions| Sequencers Users -->|query data| Verifiers Sequencers -->|submit transaction batches| EthereumL1 Sequencers -.->|fetch deposit data| EthereumL1 classDef l1Contracts stroke:#bbf,stroke-width:2px; classDef l2Components stroke:#333,stroke-width:2px; classDef systemUser stroke:#f9a,stroke-width:2px; class EthereumL1 l1Contracts; class Users,Sequencers,Verifiers l2Components;","breadcrumbs":"Background » Network Participants","id":"14","title":"Network Participants"},"140":{"body":"The following table gives an overview of some protocol parameters, and how they are affected by protocol upgrades. Parameter Bedrock (default) value Latest (default) value Changes Notes max_sequencer_drift 600 1800 Fjord Changed from a chain parameter to a constant with Fjord. MAX_RLP_BYTES_PER_CHANNEL 10,000,000 100,000,000 Fjord Constant increased with Fjord. MAX_CHANNEL_BANK_SIZE 100,000,000 1,000,000,000 Fjord Constant increased with Fjord. MAX_SPAN_BATCH_ELEMENT_COUNT 10,000,000 10,000,000 Effectively introduced in Fjord Number of elements","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Protocol Parameters","id":"140","title":"Protocol Parameters"},"141":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission","id":"141","title":"Batch Submission"},"142":{"body":"The sequencer accepts L2 transactions from users. It is responsible for building blocks out of these. For each such block, it also creates a corresponding sequencer batch . It is also responsible for submitting each batch to a data availability provider (e.g. Ethereum calldata), which it does via its batcher component. The difference between an L2 block and a batch is subtle but important: the block includes an L2 state root, whereas the batch only commits to transactions at a given L2 timestamp (equivalently: L2 block number). A block also includes a reference to the previous block (*). (*) This matters in some edge case where a L1 reorg would occur and a batch would be reposted to the L1 chain but not the preceding batch, whereas the predecessor of an L2 block cannot possibly change. This means that even if the sequencer applies a state transition incorrectly, the transactions in the batch will still be considered part of the canonical L2 chain. Batches are still subject to validity checks (i.e. they have to be encoded correctly), and so are individual transactions within the batch (e.g. signatures have to be valid). Invalid batches and invalid individual transactions within an otherwise valid batch are discarded by correct nodes. If the sequencer applies a state transition incorrectly and posts an output root , then this output root will be incorrect. The incorrect output root will be challenged by a fault proof , then replaced by a correct output root for the existing sequencer batches. Refer to the Batch Submission specification for more information.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Sequencing & Batch Submission Overview","id":"142","title":"Sequencing & Batch Submission Overview"},"143":{"body":"Batch submission is closely tied to L2 chain derivation because the derivation process must decode the batches that have been encoded for the purpose of batch submission. The batcher submits batcher transactions to a data availability provider . These transactions contain one or multiple channel frames , which are chunks of data belonging to a channel . A channel is a sequence of sequencer batches (for any L2 blocks) compressed together. The reason to group multiple batches together is simply to obtain a better compression rate, hence reducing data availability costs. Channels might be too large to fit in a single batcher transaction , hence we need to split it into chunks known as channel frames . A single batcher transaction can also carry multiple frames (belonging to the same or to different channels). This design gives use the maximum flexibility in how we aggregate batches into channels, and split channels over batcher transactions. It notably allows us to maximize data utilization in a batcher transaction: for instance it allows us to pack the final (small) frame of one channel with one or more frames from the next channel. Also note that we use a streaming compression scheme, and we do not need to know how many batches a channel will end up containing when we start a channel, or even as we send the first frames in the channel. And by splitting channels across multiple data transactions, the L2 can have larger block data than the data-availability layer may support. All of this is illustrated in the following diagram. Explanations below. batch derivation chain diagram The first line represents L1 blocks with their numbers. The boxes under the L1 blocks represent batcher transactions included within the block. The squiggles under the L1 blocks represent deposits (more specifically, events emitted by the deposit contract ). Each colored chunk within the boxes represents a channel frame . So A and B are channels whereas A0, A1, B0, B1, B2 are frames. Notice that: multiple channels are interleaved frames do not need to be transmitted in order a single batcher transaction can carry frames from multiple channels In the next line, the rounded boxes represent individual sequencer batches that were extracted from the channels. The four blue/purple/pink were derived from channel A while the other were derived from channel B. These batches are here represented in the order they were decoded from batches (in this case B is decoded first). Note The caption here says \"Channel B was seen first and will be decoded into batches first\", but this is not a requirement. For instance, it would be equally acceptable for an implementation to peek into the channels and decode the one that contains the oldest batches first. The rest of the diagram is conceptually distinct from the first part and illustrates L2 chain derivation after the channels have been reordered. The first line shows batcher transactions. Note that in this case, there exists an ordering of the batches that makes all frames within the channels appear contiguously. This is not true in general. For instance, in the second transaction, the position of A1 and B0 could have been inverted for exactly the same result — no changes needed in the rest of the diagram. The second line shows the reconstructed channels in proper order. The third line shows the batches extracted from the channel. Because the channels are ordered and the batches within a channel are sequential, this means the batches are ordered too. The fourth line shows the L2 block derived from each batch. Note that we have a 1-1 batch to block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there are \"gaps\" in the batches posted on L1. The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while the second number (the \"sequence number\") denotes the position within the epoch. Finally, the sixth line shows user-deposited transactions derived from the deposit contract event mentioned earlier. Note the 101-0 L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if frame B2 indicates that it is the last frame within the channel and (2) no empty blocks must be inserted. The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4 blocks, because the last frame of channel A appears in block 102, but belong to epoch 99. As for the comment on \"security types\", it explains the classification of blocks as used on L1 and L2. Unsafe L2 blocks : Safe L2 blocks : Finalized L2 blocks: refer to block that have been derived from finalized L1 data. These security levels map to the headBlockHash, safeBlockHash and finalizedBlockHash values transmitted when interacting with the execution-engine API .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission Wire Format","id":"143","title":"Batch Submission Wire Format"},"144":{"body":"Batcher transactions are encoded as version_byte ++ rollup_payload (where ++ denotes concatenation). version_byte rollup_payload 0 frame ... (one or more frames, concatenated) 1 da_commitment (experimental, see alt-da ) Unknown versions make the batcher transaction invalid (it must be ignored by the rollup node). All frames in a batcher transaction must be parseable. If any one frame fails to parse, the all frames in the transaction are rejected. Batch transactions are authenticated by verifying that the to address of the transaction matches the batch inbox address, and the from address matches the batch-sender address in the system configuration at the time of the L1 block that the transaction data is read from.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batcher Transaction Format","id":"144","title":"Batcher Transaction Format"},"145":{"body":"A channel frame is encoded as: frame = channel_id ++ frame_number ++ frame_data_length ++ frame_data ++ is_last channel_id = bytes16\nframe_number = uint16\nframe_data_length = uint32\nframe_data = bytes\nis_last = bool Where uint32 and uint16 are all big-endian unsigned integers. Type names should be interpreted to and encoded according to the Solidity ABI . All data in a frame is fixed-size, except the frame_data. The fixed overhead is 16 + 2 + 4 + 1 = 23 bytes. Fixed-size frame metadata avoids a circular dependency with the target total data length, to simplify packing of frames with varying content length. where: channel_id is an opaque identifier for the channel. It should not be reused and is suggested to be random; however, outside of timeout rules, it is not checked for validity frame_number identifies the index of the frame within the channel frame_data_length is the length of frame_data in bytes. It is capped to 1,000,000 bytes. frame_data is a sequence of bytes belonging to the channel, logically after the bytes from the previous frames is_last is a single byte with a value of 1 if the frame is the last in the channel, 0 if there are frames in the channel. Any other value makes the frame invalid (it must be ignored by the rollup node).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Format","id":"145","title":"Frame Format"},"146":{"body":"A channel is encoded by applying a streaming compression algorithm to a list of batches: rlp_batches = []\nfor batch in batches: rlp_batches.append(batch) where: batches is the input, a sequence of batches byte-encoded as per the next section (\"Batch Encoding\") rlp_batches is the concatenation of the RLP-encoded batches channel_encoding = zlib_compress(rlp_batches) where zlib_compress is the ZLIB algorithm (as specified in RFC-1950 ) with no dictionary. The Fjord upgrade introduces an additional versioned channel encoding format to support alternate compression algorithms. When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL (defined in the Protocol Parameters table ), in order to avoid \"zip-bomb\" types of attack (where a small compressed input decompresses to a humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained only the first MAX_RLP_BYTES_PER_CHANNEL decompressed bytes. The limit is set on RLP decoding, so all batches that can be decoded in MAX_RLP_BYTES_PER_CHANNEL will be accepted even if the size of the channel is greater than MAX_RLP_BYTES_PER_CHANNEL. The exact requirement is that length(input) <= MAX_RLP_BYTES_PER_CHANNEL. While the above pseudocode implies that all batches are known in advance, it is possible to perform streaming compression and decompression of RLP-encoded batches. This means it is possible to start including channel frames in a batcher transaction before we know how many batches (and how many frames) the channel will contain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Format","id":"146","title":"Channel Format"},"147":{"body":"Recall that a batch contains a list of transactions to be included in a specific L2 block. A batch is encoded as batch_version ++ content, where content depends on the batch_version. Prior to the Delta upgrade, batches all have batch_version 0 and are encoded as described below. batch_version content 0 rlp_encode([parent_hash, epoch_number, epoch_hash, timestamp, transaction_list]) where: batch_version is a single byte, prefixed before the RLP contents, alike to transaction typing. rlp_encode is a function that encodes a batch according to the RLP format , and [x, y, z] denotes a list containing items x, y and z parent_hash is the block hash of the previous L2 block epoch_number and epoch_hash are the number and hash of the L1 block corresponding to the sequencing epoch of the L2 block timestamp is the timestamp of the L2 block transaction_list is an RLP-encoded list of EIP-2718 encoded transactions. The Delta upgrade introduced an additional batch type, span batches . Unknown versions make the batch invalid (it must be ignored by the rollup node), as do malformed contents. The epoch_number and the timestamp must also respect the constraints listed in the Batch Queue section, otherwise the batch is considered invalid and will be ignored.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Format","id":"147","title":"Batch Format"},"148":{"body":"The above primarily describes the general encodings used in L2 chain derivation, primarily how batches are encoded within batcher transactions . This section describes how the L2 chain is produced from the L1 batches using a pipeline architecture. A verifier may implement this differently, but must be semantically equivalent to not diverge from the L2 chain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Architecture","id":"148","title":"Architecture"},"149":{"body":"Our architecture decomposes the derivation process into a pipeline made up of the following stages: L1 Traversal L1 Retrieval Frame Queue Channel Bank Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue The data flows from the start (outer) of the pipeline towards the end (inner). From the innermost stage the data is pulled from the outermost stage. However, data is processed in reverse order. Meaning that if there is any data to be processed in the last stage, it will be processed first. Processing proceeds in \"steps\" that can be taken at each stage. We try to take as many steps as possible in the last (most inner) stage before taking any steps in its outer stage, etc. This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing the derivation pipeline. Each stage can maintain its own inner state as necessary. In particular, each stage maintains a L1 block reference (number + hash) to the latest L1 block such that all data originating from previous blocks has been fully processed, and the data from that block is being or has been processed. This allows the innermost stage to account for finalization of the L1 data-availability used to produce the L2 chain, to reflect in the L2 chain forkchoice when the L2 chain inputs become irreversible. Let's briefly describe each stage of the pipeline.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Pipeline","id":"149","title":"L2 Chain Derivation Pipeline"},"15":{"body":"Users are the general class of network participants who: Submit transactions through a Sequencer or by interacting with contracts on Ethereum. Query transaction data from interfaces operated by verifiers.","breadcrumbs":"Background » Users","id":"15","title":"Users"},"150":{"body":"In the L1 Traversal stage, we simply read the header of the next L1 block. In normal operations, these will be new L1 blocks as they get created, though we can also read old blocks while syncing, or in case of an L1 re-org . Upon traversal of the L1 block, the system configuration copy used by the L1 retrieval stage is updated, such that the batch-sender authentication is always accurate to the exact L1 block that is read by the stage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Traversal","id":"150","title":"L1 Traversal"},"151":{"body":"In the L1 Retrieval stage, we read the block we get from the outer stage (L1 traversal), and extract data from its batcher transactions . A batcher transaction is one with the following properties: The to field is equal to the configured batcher inbox address. The sender, as recovered from the transaction signature (v, r, and s), is the batcher address loaded from the system config matching the L1 block of the data. Each batcher transaction is versioned and contains a series of channel frames to be read by the Frame Queue, see Batch Submission Wire Format . Each batcher transaction in the block is processed in the order they appear in the block by passing its calldata on to the next phase.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Retrieval","id":"151","title":"L1 Retrieval"},"152":{"body":"The Frame Queue buffers one data-transaction at a time, decoded into channel frames , to be consumed by the next stage. See Batcher transaction format and Frame format specifications.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Queue","id":"152","title":"Frame Queue"},"153":{"body":"The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1 retrieval stage. A step in the channel bank stage tries to read data from channels that are \"ready\". Channels are currently fully buffered until read or dropped, streaming channels may be supported in a future version of the ChannelBank. To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels. Channels are recorded in FIFO order in a structure called the channel queue . A channel is added to the channel queue the first time a frame belonging to the channel is seen. Pruning After successfully inserting a new frame, the ChannelBank is pruned: channels are dropped in FIFO order, until total_size <= MAX_CHANNEL_BANK_SIZE, where: total_size is the sum of the sizes of each channel, which is the sum of all buffered frame data of the channel, with an additional frame-overhead of 200 bytes per frame. MAX_CHANNEL_BANK_SIZE is a protocol constant defined in the Protocol Parameters table . Timeouts The L1 origin that the channel was opened in is tracked with the channel as channel.open_l1_block, and determines the maximum span of L1 blocks that the channel data is retained for, before being pruned. A channel is timed out if: current_l1_block.number > channel.open_l1_block.number + CHANNEL_TIMEOUT, where: current_l1_block is the L1 origin that the stage is currently traversing. CHANNEL_TIMEOUT is a rollup-configurable, expressed in number of L1 blocks. New frames for timed-out channels are dropped instead of buffered. Reading Upon reading, while the first opened channel is timed-out, remove it from the channel-bank. Prior to the Canyon network upgrade, once the first opened channel, if any, is not timed-out and is ready, then it is read and removed from the channel-bank. After the Canyon network upgrade, the entire channel bank is scanned in FIFO order (by open time) & the first ready (i.e. not timed-out) channel will be returned. The canyon behavior will activate when frames from a L1 block whose timestamp is greater than or equal to the canyon time first enter the channel queue. A channel is ready if: The channel is closed The channel has a contiguous sequence of frames until the closing frame If no channel is ready, the next frame is read and ingested into the channel bank. Loading frames When a channel ID referenced by a frame is not already present in the Channel Bank, a new channel is opened, tagged with the current L1 block, and appended to the channel-queue. Frame insertion conditions: New frames matching timed-out channels that have not yet been pruned from the channel-bank are dropped. Duplicate frames (by frame number) for frames that have not been pruned from the channel-bank are dropped. Duplicate closes (new frame is_last == 1, but the channel has already seen a closing frame and has not yet been pruned from the channel-bank) are dropped. If a frame is closing (is_last == 1) any existing higher-numbered frames are removed from the channel. Note that while this allows channel IDs to be reused once they have been pruned from the channel-bank, it is recommended that batcher implementations use unique channel IDs.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Bank","id":"153","title":"Channel Bank"},"154":{"body":"In this stage, we decompress the channel we pull from the last stage, and then parse batches from the decompressed byte stream. See Channel Format and Batch Format for decompression and decoding specification.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Reader (Batch Decoding)","id":"154","title":"Channel Reader (Batch Decoding)"},"155":{"body":"During the Batch Buffering stage, we reorder batches by their timestamps. If batches are missing for some time slots and a valid batch with a higher timestamp exists, this stage also generates empty batches to fill the gaps. Batches are pushed to the next stage whenever there is one sequential batch directly following the timestamp of the current safe L2 head (the last block that can be derived from the canonical L1 chain). The parent hash of the batch must also match the hash of the current safe L2 head. Note that the presence of any gaps in the batches derived from L1 means that this stage will need to buffer for a whole sequencing window before it can generate empty batches (because the missing batch(es) could have data in the last L1 block of the window in the worst case). A batch can have 4 different forms of validity: drop: the batch is invalid, and will always be in the future, unless we reorg. It can be removed from the buffer. accept: the batch is valid and should be processed. undecided: we are lacking L1 information until we can proceed batch filtering. future: the batch may be valid, but cannot be processed yet and should be checked again later. The batches are processed in order of the inclusion on L1: if multiple batches can be accept-ed the first is applied. An implementation can defer future batches a later derivation step to reduce validation work. The batches validity is derived as follows: Definitions: batch as defined in the Batch format section . epoch = safe_l2_head.l1_origin a L1 origin coupled to the batch, with properties: number (L1 block number), hash (L1 block hash), and timestamp (L1 block timestamp). inclusion_block_number is the L1 block number when batch was first fully derived, i.e. decoded and output by the previous stage. next_timestamp = safe_l2_head.timestamp + block_time is the expected L2 timestamp the next batch should have, see block time information . next_epoch may not be known yet, but would be the L1 block after epoch if available. batch_origin is either epoch or next_epoch, depending on validation. Note that processing of a batch can be deferred until batch.timestamp <= next_timestamp, since future batches will have to be retained anyway. Rules, in validation order: batch.timestamp > next_timestamp -> future: i.e. the batch must be ready to process. batch.timestamp < next_timestamp -> drop: i.e. the batch must not be too old. batch.parent_hash != safe_l2_head.hash -> drop: i.e. the parent hash must be equal to the L2 safe head block hash. batch.epoch_num + sequence_window_size < inclusion_block_number -> drop: i.e. the batch must be included timely. batch.epoch_num < epoch.number -> drop: i.e. the batch origin is not older than that of the L2 safe head. batch.epoch_num == epoch.number: define batch_origin as epoch. batch.epoch_num == epoch.number+1: If next_epoch is not known -> undecided: i.e. a batch that changes the L1 origin cannot be processed until we have the L1 origin data. If known, then define batch_origin as next_epoch batch.epoch_num > epoch.number+1 -> drop: i.e. the L1 origin cannot change by more than one L1 block per L2 block. batch.epoch_hash != batch_origin.hash -> drop: i.e. a batch must reference a canonical L1 origin, to prevent batches from being replayed onto unexpected L1 chains. batch.timestamp < batch_origin.time -> drop: enforce the min L2 timestamp rule. batch.timestamp > batch_origin.time + max_sequencer_drift: enforce the L2 timestamp drift rule, but with exceptions to preserve above min L2 timestamp invariant: len(batch.transactions) == 0: epoch.number == batch.epoch_num: this implies the batch does not already advance the L1 origin, and must thus be checked against next_epoch. If next_epoch is not known -> undecided: without the next L1 origin we cannot yet determine if time invariant could have been kept. If batch.timestamp >= next_epoch.time -> drop: the batch could have adopted the next L1 origin without breaking the L2 time >= L1 time invariant. len(batch.transactions) > 0: -> drop: when exceeding the sequencer time drift, never allow the sequencer to include transactions. batch.transactions: drop if the batch.transactions list contains a transaction that is invalid or derived by other means exclusively: any transaction that is empty (zero length byte string) any deposited transactions (identified by the transaction type prefix byte) If no batch can be accept-ed, and the stage has completed buffering of all batches that can fully be read from the L1 block at height epoch.number + sequence_window_size, and the next_epoch is available, then an empty batch can be derived with the following properties: parent_hash = safe_l2_head.hash timestamp = next_timestamp transactions is empty, i.e. no sequencer transactions. Deposited transactions may be added in the next stage. If next_timestamp < next_epoch.time: the current L1 origin is repeated, to preserve the L2 time invariant. epoch_num = epoch.number epoch_hash = epoch.hash If the batch is the first batch of the epoch, that epoch is used instead of advancing the epoch to ensure that there is at least one L2 block per epoch. epoch_num = epoch.number epoch_hash = epoch.hash Otherwise, epoch_num = next_epoch.number epoch_hash = next_epoch.hash","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Queue","id":"155","title":"Batch Queue"},"156":{"body":"In the Payload Attributes Derivation stage, we convert the batches we get from the previous stage into instances of the PayloadAttributes structure. Such a structure encodes the transactions that need to figure into a block, as well as other block inputs (timestamp, fee recipient, etc). Payload attributes derivation is detailed in the section Deriving Payload Attributes section below. This stage maintains its own copy of the system configuration , independent of the L1 retrieval stage. The system configuration is updated with L1 log events whenever the L1 epoch referenced by the batch input changes.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Payload Attributes Derivation","id":"156","title":"Payload Attributes Derivation"},"157":{"body":"In the Engine Queue stage, the previously derived PayloadAttributes structures are buffered and sent to the execution engine to be executed and converted into a proper L2 block. The stage maintains references to three L2 blocks: The finalized L2 head : everything up to and including this block can be fully derived from the finalized (i.e. canonical and forever irreversible) part of the L1 chain. The safe L2 head : everything up to and including this block can be fully derived from the currently canonical L1 chain. The unsafe L2 head : blocks between the safe and unsafe heads are unsafe blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer mode) or from unsafe sync to the sequencer (in validator mode). This is also known as the \"latest\" head. Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references from which L1 blocks each was derived. This history does not have to be complete, but enables later L1 finality signals to be translated into L2 finality. Engine API usage To interact with the engine, the execution engine API is used, with the following JSON-RPC methods: Bedrock, Canyon, Delta: API Usage engine_forkchoiceUpdatedV2 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV2 — retrieves a previously requested execution payload build. engine_newPayloadV2 — executes an execution payload to create a block. Ecotone: API Usage engine_forkchoiceUpdatedV3 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV3 — retrieves a previously requested execution payload build. engine_newPayload engine_newPayloadV2 — executes a Bedrock/Canyon/Delta execution payload to create a block. engine_newPayloadV3 — executes an Ecotone execution payload to create a block. The current version of op-node uses the v3 Engine API RPC methods as well as engine_newPayloadV2, due to engine_newPayloadV3 only supporting Ecotone execution payloads. Both engine_forkchoiceUpdatedV3 and engine_getPayloadV3 are backwards compatible with Bedrock, Canyon & Delta payloads. Prior versions of op-node used v2 and v1 methods. The execution payload is an object of type ExecutionPayloadV3 . The ExecutionPayload has the following requirements: Bedrock The withdrawals field MUST be nil The blob gas used field MUST be nil The blob gas limit field MUST be nil Canyon, Delta The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be nil The blob gas limit field MUST be nil Ecotone The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be 0 The blob gas limit field MUST be 0 Forkchoice synchronization If there are any forkchoice updates to be applied, before additional inputs are derived or processed, then these are applied to the engine first. This synchronization may happen when: A L1 finality signal finalizes one or more L2 blocks: updating the \"finalized\" L2 block. A successful consolidation of unsafe L2 blocks: updating the \"safe\" L2 block. The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state. The new forkchoice state is applied by calling fork choice updated on the engine API. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. L1-consolidation: payload attributes matching If the unsafe head is ahead of the safe head, then consolidation is attempted, verifying that existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data. During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If the payload attributes match this oldest unsafe L2 block, then that block can be considered \"safe\" and becomes the new safe head. The following fields of the derived L2 payload attributes are checked for equality with the L2 block: Bedrock, Canyon, Delta, Ecotone Blocks parent_hash timestamp randao fee_recipient transactions_list (first length, then equality of each of the encoded transactions, including deposits) gas_limit Canyon, Delta, Ecotone Blocks withdrawals (first presence, then length, then equality of each of the encoded withdrawals) Ecotone Blocks parent_beacon_block_root If consolidation succeeds, the forkchoice change will synchronize as described in the section above. If consolidation fails, the L2 payload attributes will be processed immediately as described in the section below. The payload attributes are chosen in favor of the previous unsafe L2 block, creating an L2 chain reorg on top of the current safe block. Immediately processing the new alternative attributes enables execution engines like go-ethereum to enact the change, as linear rewinds of the tip of the chain may not be supported. L1-sync: payload attributes processing If the safe and unsafe L2 heads are identical (whether because of failed consolidation or not), we send the L2 payload attributes to the execution engine to be constructed into a proper L2 block. This L2 block will then become both the new L2 safe and unsafe head. If a payload attributes created from a batch cannot be inserted into the chain because of a validation error (i.e. there was an invalid transaction or state transition in the block) the batch should be dropped & the safe head should not be advanced. The engine queue will attempt to use the next batch for that timestamp from the batch queue. If no valid batch is found, the rollup node will create a deposit only batch which should always pass validation because deposits are always valid. Interaction with the execution engine via the execution engine API is detailed in the Communication with the Execution Engine section. The payload attributes are then processed with a sequence of: Engine: Fork choice updated with current forkchoice state of the stage, and the attributes to start block building. Non-deterministic sources, like the tx-pool, must be disabled to reconstruct the expected block. Engine: Get Payload to retrieve the payload, by the payload-ID in the result of the previous step. Engine: New Payload to import the new payload into the execution engine. Engine: Fork Choice Updated to make the new payload canonical, now with a change of both safe and unsafe fields to refer to the payload, and no payload attributes. Engine API Error handling: On RPC-type errors the payload attributes processing should be re-attempted in a future step. On payload processing errors the attributes must be dropped, and the forkchoice state must be left unchanged. Eventually the derivation pipeline will produce alternative payload attributes, with or without batches. If the payload attributes only contained deposits, then it is a critical derivation error if these are invalid. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. Processing unsafe payload attributes If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as an \"unsafe\" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the user to see the head of the L2 chain faster than the L1 may confirm the L2 batches. To process unsafe payloads, the payload must: Have a block number higher than the current safe L2 head. The safe L2 head may only be reorged out due to L1 reorgs. Have a parent blockhash that matches the current unsafe L2 head. This prevents the execution engine individually syncing a larger gap in the unsafe L2 chain. This prevents unsafe L2 blocks from reorging other previously validated L2 blocks. This check may change in the future versions to adopt e.g. the L1 snap-sync protocol. The payload is then processed with a sequence of: Bedrock/Canyon/Delta Payloads engine_newPayloadV2: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV2: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Ecotone Payloads engine_newPayloadV3: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV3: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Engine API Error handling: On RPC-type errors the payload processing should be re-attempted in a future step. On payload processing errors the payload must be dropped, and not be marked as canonical. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Engine Queue","id":"157","title":"Engine Queue"},"158":{"body":"It is possible to reset the pipeline, for instance if we detect an L1 reorg (reorganization) . This enables the rollup node to handle L1 chain reorg events. Resetting will recover the pipeline into a state that produces the same outputs as a full L2 derivation process, but starting from an existing L2 chain that is traversed back just enough to reconcile with the current L1 chain. Note that this algorithm covers several important use-cases: Initialize the pipeline without starting from 0, e.g. when the rollup node restarts with an existing engine instance. Recover the pipeline if it becomes inconsistent with the execution engine chain, e.g. when the engine syncs/changes. Recover the pipeline when the L1 chain reorganizes, e.g. a late L1 block is orphaned, or a larger attestation failure. Initialize the pipeline to derive a disputed L2 block with prior L1 and L2 history inside a fault-proof program. Handling these cases also means a node can be configured to eagerly sync L1 data with 0 confirmations, as it can undo the changes if the L1 later does recognize the data as canonical, enabling safe low-latency usage. The Engine Queue is first reset, to determine the L1 and L2 starting points to continue derivation from. After this, the other stages are reset independent of each other. Finding the sync starting point To find the starting point, there are several steps, relative to the head of the chain traversing back: Find the current L2 forkchoice state If no finalized block can be found, start at the Bedrock genesis block. If no safe block can be found, fallback to the finalized block. The unsafe block should always be available and consistent with the above (it may not be in rare engine-corruption recovery cases, this is being reviewed). Find the first L2 block with plausible L1 reference to be the new unsafe starting point, starting from previous unsafe, back to finalized and no further. Plausible iff: the L1 origin of the L2 block is known and canonical, or unknown and has a block-number ahead of L1. Find the first L2 block with an L1 reference older than the sequencing window, to be the new safe starting point, starting at the above plausible unsafe head, back to finalized and no further. If at any point the L1 origin is known but not canonical, the unsafe head is revised to parent of the current. The highest L2 block with known canonical L1 origin is remembered as highest. If at any point the L1 origin in the block is corrupt w.r.t. derivation rules, then error. Corruption includes: Inconsistent L1 origin block number or parent-hash with parent L1 origin Inconsistent L1 sequence number (always changes to 0 for a L1 origin change, or increments by 1 if not) If the L1 origin of the L2 block n is older than the L1 origin of highest by more than a sequence window, and n.sequence_number == 0, then the parent L2 block of n will be the safe starting point. The finalized L2 block persists as the finalized starting point. Find the first L2 block with an L1 reference older than the channel-timeout The L1 origin referenced by this block which we call l2base will be the base for the L2 pipeline derivation: By starting here, the stages can buffer any necessary data, while dropping incomplete derivation outputs until L1 traversal has caught up with the actual L2 safe head. While traversing back the L2 chain, an implementation may sanity-check that the starting point is never set too far back compared to the existing forkchoice state, to avoid an intensive reorg because of misconfiguration. Implementers note: step 1-4 are known as FindL2Heads. Step 5 is currently part of the Engine Queue reset. This may change to isolate the starting-point search from the bare reset logic. Resetting derivation stages L1 Traversal: start at L1 base as first block to be pulled by next stage. L1 Retrieval: empty previous data, and fetch the base L1 data, or defer the fetching work to a later pipeline step. Frame Queue: empty the queue. Channel Bank: empty the channel bank. Channel Reader: reset any batch decoding state. Batch Queue: empty the batch queue, use base as initial L1 point of reference. Payload Attributes Derivation: empty any batch/attributes state. Engine Queue: Initialize L2 forkchoice state with syncing start point state. (finalized/safe/unsafe) Initialize the L1 point of reference of the stage to base. Require a forkchoice update as first task Reset any finality data Where necessary, stages starting at base can initialize their system-config from data encoded in the l2base block. About reorgs Post-Merge Note that post- merge , the depth of reorgs will be bounded by the L1 finality delay (2 L1 beacon epochs, or approximately 13 minutes, unless more than 1/3 of the network consistently disagrees). New L1 blocks may be finalized every L1 beacon epoch (approximately 6.4 minutes), and depending on these finality-signals and batch-inclusion, the derived L2 chain will become irreversible as well. Note that this form of finalization only affects inputs, and nodes can then subjectively say the chain is irreversible, by reproducing the chain from these irreversible inputs and the set protocol rules and parameters. This is however completely unrelated to the outputs posted on L1, which require a form of proof like a fault-proof or zk-proof to finalize. Optimistic-rollup outputs like withdrawals on L1 are only labeled \"finalized\" after passing a week without dispute (fault proof challenge window), a name-collision with the proof-of-stake finalization.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Resetting the Pipeline","id":"158","title":"Resetting the Pipeline"},"159":{"body":"For every L2 block derived from L1 data, we need to build payload attributes , represented by an expanded version of the PayloadAttributesV2 object, which includes additional transactions and noTxPool fields. This process happens during the payloads-attributes queue ran by a verifier node, as well as during block-production ran by a sequencer node (the sequencer may enable the tx-pool usage if the transactions are batch-submitted).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving Payload Attributes","id":"159","title":"Deriving Payload Attributes"},"16":{"body":"Sequencers fill the role of the block producer on an OP Stack chain. Chains may have a single Sequencer or may choose to utilize some consensus protocol that coordinates multiple Sequencers. The OP Stack currently officially only supports a single active Sequencer at any given time. In general, specifications may use the term \"the Sequencer\" as a stand-in for either a single Sequencer or a consensus protocol of multiple Sequencers. The Sequencer: Accepts transactions directly from Users. Observes \"deposit\" transactions generated on Ethereum. Consolidates both transaction streams into ordered L2 blocks. Submits information to L1 that is sufficient to fully reproduce those L2 blocks. Provides real-time access to pending L2 blocks that have not yet been confirmed on L1. The Sequencer serves an important role for the operation of an L2 chain but is not a trusted actor. The Sequencer is generally responsible for improving the user experience by ordering transactions much more quickly and cheaply than would currently be possible if users were to submit all transactions directly to L1.","breadcrumbs":"Background » Sequencers","id":"16","title":"Sequencers"},"160":{"body":"For each L2 block to be created by the sequencer, we start from a sequencer batch matching the target L2 block number. This could potentially be an empty auto-generated batch, if the L1 chain did not include a batch for the target L2 block number. Remember that the batch includes a sequencing epoch number, an L2 timestamp, and a transaction list. This block is part of a sequencing epoch , whose number matches that of an L1 block (its L1 origin ). This L1 block is used to derive L1 attributes and (for the first L2 block in the epoch) user deposits. Therefore, a PayloadAttributesV2 object must include the following transactions: one or more deposited transactions , of two kinds: a single L1 attributes deposited transaction , derived from the L1 origin. for the first L2 block in the epoch, zero or more user-deposited transactions , derived from the receipts of the L1 origin. zero or more network upgrade automation transactions : special transactions to perform network upgrades. zero or more sequenced transactions : regular transactions signed by L2 users, included in the sequencer batch. Transactions must appear in this order in the payload attributes. The L1 attributes are read from the L1 block header, while deposits are read from the L1 block's receipts . Refer to the deposit contract specification for details on how deposits are encoded as log entries.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving the Transaction List","id":"160","title":"Deriving the Transaction List"},"161":{"body":"Some network upgrades require automated contract changes or deployments at specific blocks. To automate these, without adding persistent changes to the execution-layer, special transactions may be inserted as part of the derivation process. Ecotone The Ecotone hardfork activation block contains the following transactions, in this order: L1 Attributes Transaction, using the pre-Ecotone setL1BlockValues User deposits from L1 Network Upgrade Transactions L1Block deployment GasPriceOracle deployment Update L1Block Proxy ERC-1967 Implementation Slot Update GasPriceOracle Proxy ERC-1967 Implementation Slot GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) To not modify or interrupt the system behavior around gas computation, this block will not include any sequenced transactions by setting noTxPool: true. L1Block Deployment The L1Block contract is upgraded to process the new Ecotone L1-data-fee parameters and L1 blob base-fee. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000000 to: null mint: 0 value: 0 gasLimit: 375,000 data: 0x60806040523480156100105... ( full bytecode ) sourceHash: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Deployment\" This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000000\nComputed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Deployment\"))\n# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json This transaction MUST deploy a contract with the following code hash 0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd. GasPriceOracle Deployment The GasPriceOracle contract is upgraded to support the new Ecotone L1-data-fee parameters. Post fork this contract will use the blob base fee to compute the gas price for L1-data-fee transactions. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000001 to: null, mint: 0 value: 0 gasLimit: 1,000,000 data: 0x60806040523480156100... ( full bytecode ) sourceHash: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Deployment\" This results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000001\nComputed Address: 0xb528D11cC114E026F138fE568744c6D45ce6Da7A Verify sourceHash: ❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Deployment\"))\n# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json This transaction MUST deploy a contract with the following code hash 0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5. L1Block Proxy Update This transaction updates the L1Block Proxy ERC-1967 implementation slot to point to the new L1Block deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x4200000000000000000000000000000000000015 (L1Block Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff sourceHash: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)\n0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Proxy Update\"))\n# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc GasPriceOracle Proxy Update This transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a sourceHash: 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: Gas Price Oracle Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)\n0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Proxy Update\"))\n# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a GasPriceOracle Enable Ecotone This transaction informs the GasPriceOracle to start using the Ecotone gas calculation formula. A deposit transaction is derived with the following attributes: from: 0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 (Depositer Account) to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 80,000 data: 0x22b90ab3 sourceHash: 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Set Ecotone\" Verify data: cast sig \"setEcotone()\"\n0x22b90ab3 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Set Ecotone\"))\n# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93 Beacon block roots contract deployment (EIP-4788) EIP-4788 introduces a \"Beacon block roots\" contract, that processes and exposes the beacon-block-root values. at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02. For deployment, EIP-4788 defines a pre- EIP-155 legacy transaction, sent from a key that is derived such that the transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code. However, this type of transaction requires manual deployment and gas-payments. And since the processing is an integral part of the chain processing, and has to be repeated for every OP-Stack chain, the deployment is approached differently here. Some chains may already have a user-submitted instance of the EIP-4788 transaction. This is cryptographically guaranteed to be correct, but may result in the upgrade transaction deploying a second contract, with the next nonce. The result of this deployment can be ignored. A Deposit transaction is derived with the following attributes: from: 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875, as specified in the EIP. to: null mint: 0 value: 0 gasLimit: 0x3d090, as specified in the EIP. isCreation: true data: 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500 isSystemTx: false, as per the Regolith upgrade, even the system-generated transactions spend gas. sourceHash: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c, computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: beacon block roots contract deployment\" The contract address upon deployment is computed as rlp([sender, nonce]), which will equal: BEACON_ROOTS_ADDRESS if deployed a different address (0xE3aE1Ae551eeEda337c0BfF6C4c7cbA98dce353B) if nonce = 1: when a user already submitted the EIP transaction before the upgrade. Verify BEACON_ROOTS_ADDRESS: cast compute-address --nonce=0 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875\n# Computed Address: 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: beacon block roots contract deployment\"))\n# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Network upgrade automation transactions","id":"161","title":"Network upgrade automation transactions"},"162":{"body":"After deriving the transactions list, the rollup node constructs a PayloadAttributesV2 as follows: timestamp is set to the batch's timestamp. random is set to the prev_randao L1 block attribute. suggestedFeeRecipient is set to the Sequencer Fee Vault address. See Fee Vaults specification. transactions is the array of the derived transactions: deposited transactions and sequenced transactions, all encoded with EIP-2718 . noTxPool is set to true, to use the exact above transactions list when constructing the block. gasLimit is set to the current gasLimit value in the system configuration of this payload. withdrawals is set to nil prior to Canyon and an empty array after Canyon","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Building Individual Payload Attributes","id":"162","title":"Building Individual Payload Attributes"},"163":{"body":"Table of Contents Overview","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Batch Submitter","id":"163","title":"Batch Submitter"},"164":{"body":"The batch submitter, also referred to as the batcher, is the entity submitting the L2 sequencer data to L1, to make it available for verifiers. The format of the data transactions is defined in the derivation spec : the data is constructed from L2 blocks in the reverse order as it is derived from data into L2 blocks. The timing, operation and transaction signing is implementation-specific: any data can be submitted at any time, but only the data that matches the derivation spec rules will be valid from the verifier perspective. The most minimal batcher implementation can be defined as a loop of the following operations: See if the unsafe L2 block number is past the safe block number: unsafe data needs to be submitted. Iterate over all unsafe L2 blocks, skip any that were previously submitted. Open a channel, buffer all the L2 block data to be submitted, while applying the encoding and compression as defined in the derivation spec . Pull frames from the channel to fill data transactions with, until the channel is empty. Submit the data transactions to L1 The L2 view of safe/unsafe does not instantly update after data is submitted, nor when it gets confirmed on L1, so special care may have to be taken to not duplicate data submissions.","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Overview","id":"164","title":"Overview"},"165":{"body":"Table of Contents Overview Pre-image Oracle Pre-image key types Type 0: Zero key Type 1: Local key Type 2: Global keccak256 key Type 3: Global generic key Type 4: Global SHA2-256 key Type 5: Global EIP-4844 Point-evaluation key Type 6: Global Precompile key Type 7-128: reserved range Type 129-255: application usage Bootstrapping Hinting Pre-image communication Fault Proof Program Prologue Main content Epilogue Pre-image hinting routes l1-block-header l1-transactions l1-receipts l1-precompile l2-block-header l2-transactions l2-code l2-state-node l2-output Precompile Accelerators Fault Proof VM Fault Proof Interactive Dispute Game","breadcrumbs":"OP Stack Protocol » Fault Proof » Fault Proof","id":"165","title":"Fault Proof"},"166":{"body":"A fault proof, also known as fraud proof or interactive game, consists of 3 components: Program : given a commitment to all rollup inputs (L1 data) and the dispute, verify the dispute statelessly. VM : given a stateless program and its inputs, trace any instruction step, and prove it on L1. Interactive Dispute Game : bisect a dispute down to a single instruction, and resolve the base-case using the VM. Each of these 3 components may have different implementations, which can be combined into different proof stacks, and contribute to proof diversity when resolving a dispute. \"Stateless execution\" of the program, and its individual instructions, refers to reproducing the exact same computation by authenticating the inputs with a Pre-image Oracle . Diagram of Program and VM architecture","breadcrumbs":"OP Stack Protocol » Fault Proof » Overview","id":"166","title":"Overview"},"167":{"body":"The pre-image oracle is the only form of communication between the Program (in the Client role) and the VM (in the Server role). The program uses the pre-image oracle to query any input data that is understood to be available to the user: The initial inputs to bootstrap the program. See Bootstrapping . External data not already part of the program code. See Pre-image hinting routes . The communication happens over a simple request-response wire protocol, see Pre-image communication .","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image Oracle","id":"167","title":"Pre-image Oracle"},"168":{"body":"Pre-images are identified by a bytes32 type-prefixed key: The first byte identifies the type of request. The remaining 31 bytes identify the pre-image key. Type 0: Zero key The zero prefix is illegal. This ensures all pre-image keys are non-zero, enabling storage lookup optimizations and avoiding easy mistakes with invalid zeroed keys in the EVM. Type 1: Local key Information specific to the dispute: the remainder of the key may be an index, a string, a hash, etc. Only the contract(s) managing this dispute instance may serve the value for this key: it is localized and context-dependent. This type of key is used for program bootstrapping, to identify the initial input arguments by index or name. Type 2: Global keccak256 key This type of key uses a global pre-image store contract, and is fully context-independent and permissionless. I.e. every key must have a single unique value, regardless of chain history or time. Using a global store reduces duplicate pre-image registration work, and avoids unnecessary contract redeployments per dispute. This global store contract should be non-upgradeable. Since keccak256 is a safe 32-byte hash input, the first byte is overwritten with a 2 to derive the key, while keeping the rest of the key \"readable\" (matching the original hash). Type 3: Global generic key Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments. This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:], where: x is a bytes32, which can be a hash of an arbitrary-length type of cryptographically secure commitment. sender is a bytes32 identifying the pre-image inserter address (left-padded to 32 bytes) This global store contract should be non-upgradeable. The global contract is permissionless: users can standardize around external contracts that verify pre-images (i.e. a specific sender will always be trusted for a specific kind of pre-image). The external contract verifies the pre-image before inserting it into the global store for usage by all fault proof VMs without requiring the VM or global store contract to be changed. Users may standardize around upgradeable external pre-image contracts, in case the implementation of the verification of the pre-image is expected to change. The store update function is update(x bytes32, offset uint64, span uint8, value bytes32): x is the bytes32 x that the pre-image key is computed with. Only part of the pre-image, starting at offset, and up to (incl.) 32 bytes span can be inserted at a time. Pre-images may have an undefined length (e.g. a stream), we only need to know how many bytes of value are usable. The key and offset will be hashed together to uniquely store the value and span, for later pre-image serving. This enables fault proof programs to adopt any new pre-image schemes without VM update or contract redeployment. It is up to the user to index the special pre-image values by this key scheme, as there is no way to revert it to the original commitment without knowing said commitment or value. Type 4: Global SHA2-256 key A SHA-256 pre-image. Key: the SHA-256 hash, with the first byte overwritten with the type byte: 4 ++ sha256(data)[1:]. Type 5: Global EIP-4844 Point-evaluation key An EIP-4844 point-evaluation. In an EIP-4844 blob, 4096 field elements represent the blob data. It verifies p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof. The value y is the pre-image. The value z is part of the key; the index of the point within the blob. The commitment is part of the key. Each element is proven with a point-evaluation. Key: 5 ++ keccak256(commitment ++ z)[1:], where: 5 is the type byte ++ is concatenation commitment is a bytes48, representing the KZG commitment. z is a big-endian uint256 Type 6: Global Precompile key A precompile result. It maps directly to precompiles on Ethereum. This preimage key can be used to avoid running expensive precompile operations in the program. Key: 6 ++ keccak256(precompile ++ input)[1:], where: 6 is the type byte ++ is concatenation precompile is the 20-byte address of the precompile contract input is the input to the precompile contract The result is identical to that of a call to the precompile contract, prefixed with a revert indicator: reverted ++ precompile_result. reverted is a 1-byte indicator with a 0 value if the precompile reverts for the given input, otherwise it's 1. Type 7-128: reserved range Range start and end both inclusive. This range of key types is reserved for future usage by the core protocol. E.g. version changes, contract migrations, chain-data, additional core features, etc. 128 specifically (1000 0000 in binary) is reserved for key-type length-extension (reducing the content part to 30 or less key bytes), if the need arises. Type 129-255: application usage This range of key types may be used by forks or customized versions of the fault proof protocol.","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image key types","id":"168","title":"Pre-image key types"},"169":{"body":"Initial inputs are deterministic, but not necessarily singular or global: there may be multiple different disputes at the same time, each with its own disputed claims and L1 context. To bootstrap, the program requests the initial inputs from the VM, using pre-image key type 1. The VM is aware of the external context, and maps requested pre-image keys based on their type, i.e. a local lookup for type 1, or global one for 2, and optionally support other key-types.","breadcrumbs":"OP Stack Protocol » Fault Proof » Bootstrapping","id":"169","title":"Bootstrapping"},"17":{"body":"Verifiers download and execute the L2 state transition function independently of the Sequencer. Verifiers help to maintain the integrity of the network and serve blockchain data to Users. Verifiers generally: Download rollup data from L1 and the Sequencer. Use rollup data to execute the L2 state transition function. Serve rollup data and computed L2 state information to Users. Verifiers can also act as Proposers and/or Challengers who: Submit assertions about the state of the L2 to a smart contract on L1. Validate assertions made by other participants. Dispute invalid assertions made by other participants.","breadcrumbs":"Background » Verifiers","id":"17","title":"Verifiers"},"170":{"body":"There is one more form of optional communication between client and server: pre-image hinting. Hinting is optional, and is a no-op in a L1 VM implementation. The hint itself comes at very low cost onchain: the hint can be a single write sys-call, which is instant as the memory to write as hint does not actually need to be loaded as part of the onchain proof. Hinting allows the program, when generating a proof offchain, to instruct the VM what data it is interested in. The VM can choose to execute the requested hint at any time: either locally (for standard requests), or in a modular form by redirecting the hint to tooling that may come with the VM program. Hints do not have to be executed directly: they may first just be logged to show the intents of the program, and the latest hint may be buffered for lazy execution, or dropped entirely when in read-only mode (like onchain). When the pre-image oracle serves a request, and the request cannot be served from an existing collection of pre-images (e.g. a local pre-image cache) then the VM can execute the hint to retrieve the missing pre-image(s). It is the responsibility of the program to provide sufficient hinting for every pre-image request. Some hints may have to be repeated: the VM only has to execute the last hint when handling a missing pre-image. Note that hints may produce multiple pre-images: e.g. a hint for an ethereum block with transaction list may prepare pre-images for the header, each of the transactions, and the intermediate merkle-nodes that form the transactions-list Merkle Patricia Trie. Hinting is implemented with a request-acknowledgement wire-protocol over a blocking two-way stream: := := := big-endian uint32 # length of \n := byte sequence\n := 1-byte zero value The ack informs the client that the hint has been processed. Servers may respond to hints and pre-image (see below) requests asynchronously as they are on separate streams. To avoid requesting pre-images that are not yet fetched, clients should request the pre-image only after it has observed the hint acknowledgement.","breadcrumbs":"OP Stack Protocol » Fault Proof » Hinting","id":"170","title":"Hinting"},"171":{"body":"Pre-images are communicated with a minimal wire-protocol over a blocking two-way stream. This protocol can be implemented with blocking read/write syscalls. :=
This document is not finalized and should be considered experimental.
Table of Contents
L2ToL1MessagePasser
PayloadAttributesV3
eip1559Params
The EIP-1559 parameters are encoded in the block header's nonce field and can be +configured dynamically through the SystemConfig.
nonce
SystemConfig
Holocene, like other network upgrades, is activated at a timestamp. Changes to the L2 Block execution rules are applied when the L2 Timestamp >= activation time.
L2 Timestamp >= activation time
After Holocene's activation, the L2 block header's withdrawalsRoot field will consist of the 32-byte -L2ToL1MessagePasser account storage root after the block has been executed, and after the -insertions and deletions have been applied to the trie. In other words, the storage root should be the same root -that is returned by eth_getProof at the given block number.
withdrawalsRoot
eth_getProof
Prior to holocene activation, the L2 block header's withdrawalsRoot field must be:
nil
keccak256(rlp(empty_string_code))
After Holocene activation, an L2 block header's withdrawalsRoot field is valid iff:
storageRoot
[0, 32)
Currently, to generate L2 output roots for historical blocks, an archival node is required. This directly -places a burden on users of the system in a post-fault-proofs world, where:
Placing the L2ToL1MessagePasser account storage root in the withdrawalsRoot field alleviates this burden -for users and protocol participants alike, allowing them to propose and verify other proposals with lower operating costs.
As it stands, the withdrawalsRoot field is unused within the OP Stack's header consensus format, and will never be -used for other reasons that are currently planned. Setting this value to the account storage root of the withdrawal -directly fits with the OP Stack, and makes use of the existing field in the L1 header consensus format.
Varous EL clients store historical state of accounts differently. If, as a contrived case, an OP Stack chain did not have -an outbound withdrawal for a long period of time, the node may not have access to the account storage root of the -L2ToL1MessagePasser. In this case, the client would be unable to keep consensus. However, most modern -clients are able to at the very least reconstruct the account storage root at a given block on the fly if it does not -directly store this information.
The PayloadAttributesV3 type is extended to:
PayloadAttributesV3: { @@ -9113,7 +9066,7 @@ eip1559Params encoding +eip1559Params encoding NameTypeByte Offset denominatoru32 (big-endian)[0, 4) elasticityu32 (big-endian)[4, 8) @@ -9133,19 +9086,19 @@ Execution -Rationale +Rationale This type is made available in the payload attributes to allow the block builder to dynamically control the EIP-1559 parameters of the chain. As described in the derivation - AttributesBuilder section, the derivation pipeline must populate this field from the SystemConfig during payload building, similar to how it must reference the SystemConfig for the gasLimit field. -eip1559Params in Header +eip1559Params in Header Upon Holocene activation, the L2 block header's nonce field will consist of the 8-byte eip1559Params value. -Header Validity Rules +Header Validity Rules Prior to Holocene activation, the L2 block header's nonce field is valid iff it is equal to u64(0). After Holocene activation, The L2 block header's nonce field is valid iff it is non-zero. -Encoding +Encoding The encoding of the eip1559Params value is described in eip1559Params encoding. -Rationale +Rationale By chosing to put the eip1559Params in the PayloadAttributes rather than in the L1 block info transaction, the EIP-1559 parameters for the chain are not available within history. This would place a burden on performing historical execution, as L1 would have to be consulted for fetching the values from the SystemConfig contract. @@ -9153,251 +9106,27 @@ Rationale purity of the function that computes the next block's base fee from the chain configuration, parent block header, and next block timestamp. -Overview - - -Table of Contents - -Constants -Predeploys - -L1Block - -Storage -Interface - -setHolocene -setConfig -baseFeeVaultConfig -sequencerFeeVaultConfig -l1FeeVaultConfig -l1CrossDomainMessenger -l1StandardBridge -l1ERC721Bridge -remoteChainId - - - - -FeeVault - -Interface - -config - - - - -L2CrossDomainMessenger - -Interface - - -L2ERC721Bridge - -Interface - - -L2StandardBridge - -Interface - - -OptimismMintableERC721Factory - - -Security Considerations - -GovernanceToken - - - - -This upgrade enables a deterministic L2 genesis state by moving all network -specific configuration out of the initial L2 genesis state. All network specific -configuration is sourced from deposit transactions during the initialization -of the SystemConfig. -Constants -NameValueDefinition -ConfigTypeuint8An enum representing the type of config being set -WithdrawalNetworkuint8(0) or uint8(1)0 means withdraw to L1, 1 means withdraw to L2 -RECIPIENTaddressThe account that will receive funds sent out of the FeeVault -MIN_WITHDRAWAL_AMOUNTuint256The minimum amount of native asset held in the FeeVault before withdrawal is authorized -Fee Vault Configbytes32bytes32((WithdrawalNetwork << 248) || uint256(uint88(MIN_WITHDRAWAL_AMOUNT)) || uint256(uint160(RECIPIENT))) -BASE_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.basefeevaultconfig")) - 1)The Fee Vault Config for the BaseFeeVault -L1_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.l1feevaultconfig")) - 1)The Fee Vault Config for the L1FeeVault -SEQUENCER_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.sequencerfeevaultconfig")) - 1)The Fee Vault Config for the SequencerFeeVault -L1_CROSS_DOMAIN_MESSENGER_ADDRESSbytes32(uint256(keccak256("opstack.l1crossdomainmessengeraddress")) - 1)abi.encode(address(L1CrossDomainMessengerProxy)) -L1_ERC_721_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1erc721bridgeaddress")) - 1)abi.encode(address(L1ERC721BridgeProxy)) -L1_STANDARD_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1standardbridgeaddress")) - 1)abi.encode(address(L1StandardBridgeProxy)) -REMOTE_CHAIN_IDbytes32(uint256(keccak256("opstack.remotechainid")) - 1)Chain ID of the remote chain - - -Predeploys -All network specific configuration is moved to a single contract, the L1Block predeploy. -All predeploys make calls to the L1Block contract to fetch network specific configuration -rather than reading it from local state. -graph LR - subgraph L1 - SystemConfig -- "setConfig(uint8,bytes)" --> OptimismPortal - end - subgraph L2 - L1Block - BaseFeeVault -- "baseFeeVaultConfig()(address,uint256,uint8)" --> L1Block - SequencerFeeVault -- "sequencerFeeVaultConfig()(address,uint256,uint8)" --> L1Block - L1FeeVault -- "l1FeeVaultConfig()(address,uint256,uint8)" --> L1Block - L2CrossDomainMessenger -- "l1CrossDomainMessenger()(address)" --> L1Block - L2StandardBridge -- "l1StandardBridge()(address)" --> L1Block - L2ERC721Bridge -- "l1ERC721Bridge()(address)" --> L1Block - OptimismMintableERC721Factory -- "remoteChainId()(uint256)" --> L1Block - end - OptimismPortal -- "setConfig(uint8,bytes)" --> L1Block - -L1Block -Storage -The following storage slots are defined: - -BASE_FEE_VAULT_CONFIG -L1_FEE_VAULT_CONFIG -SEQUENCER_FEE_VAULT_CONFIG -L1_CROSS_DOMAIN_MESSENGER_ADDRESS -L1_ERC_721_BRIDGE_ADDRESS -L1_STANDARD_BRIDGE_ADDRESS -REMOTE_CHAIN_ID - -Each slot MUST have a defined ConfigType that authorizes the setting of the storage slot -via a deposit transaction from the DEPOSITOR_ACCOUNT. -Interface -setHolocene -This function is meant to be called once on the activation block of the holocene network upgrade. -It MUST only be callable by the DEPOSITOR_ACCOUNT once. When it is called, it MUST call -call each getter for the network specific config and set the returndata into storage. -setConfig -This function MUST only be callable by the DEPOSITOR_ACCOUNT. It modifies the storage directly -of the L1Block contract. It MUST handle all defined ConfigTypes. To ensure a simple ABI, the -bytes value MUST be abi decoded based on the ConfigType. -function setConfig(ConfigType,bytes) - -Note that ConfigType is an enum which is an alias for a uint8. -baseFeeVaultConfig -This function MUST be called by the BaseFeeVault to fetch network specific configuration. -function baseFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -sequencerFeeVaultConfig -This function MUST be called by the SequencerFeeVault to fetch network specific configuration. -function sequencerFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1FeeVaultConfig -This function MUST be called by the L1FeeVault to fetch network specific configuration. -function l1FeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1CrossDomainMessenger -This function MUST be called by the L2CrossDomainMessenger to fetch the address of the L1CrossDomainMessenger. -function l1CrossDomainMessenger()(address) - -l1StandardBridge -This function MUST be called by the L2StandardBridge to fetch the address of the L2CrossDomainMessenger. -function l1StandardBridge()(address) - -l1ERC721Bridge -This function MUST be called by the L2ERC721Bridge to fetch the address of the L1ERC721Bridge. -function l1ERC721Bridge()(address) - -remoteChainId -This function MUST be called by the OptimismMintableERC721Factory to fetch the chain id of the remote chain. -For an L2, this is the L1 chain id. -function remoteChainId()(uint256) - -FeeVault -The following changes apply to each of the BaseFeeVault, the L1FeeVault and the SequencerFeeVault. -Interface -The following functions are updated to read from the L1Block contract: - -recipient()(address) -withdrawalNetwork()(WithdrawalNetwork) -minWithdrawalAmount()(uint256) -withdraw() - -NameCall -BaseFeeVaultL1Block.baseFeeVaultConfig() -SequencerFeeVaultL1Block.sequencerFeeVaultConfig() -L1FeeVaultL1Block.l1FeeVaultConfig() - - -config -A new function is added to fetch the full Fee Vault Config. -function config()(address,uint256,WithdrawalNetwork) - -L2CrossDomainMessenger -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1CrossDomainMessenger(): - -otherMessenger()(address) -OTHER_MESSENGER()(address) - -L2ERC721Bridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1ERC721Bridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -L2StandardBridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1StandardBridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -OptimismMintableERC721Factory -The chain id is no longer read from storage but instead is read from the L1Block contract by calling -L1Block.remoteChainId() -Security Considerations -GovernanceToken -The predeploy defined by GovernanceToken should be an empty account until it is defined by -a future hardfork. +Predeploys -Configurability +System Config Table of Contents -Overview -Constants - -ConfigType - - -SystemConfig - -ConfigUpdate -Initialization -Modifying EIP-1559 Parameters -Interface +Overview -EIP-1559 Params +ConfigUpdate +Initialization +Modifying EIP-1559 Parameters +Interface -setEIP1559Params -eip1559Elasticity -eip1559Denominator - - -Fee Vault Config +EIP-1559 Params -setBaseFeeVaultConfig -setL1FeeVaultConfig -setSequencerFeeVaultConfig - - - - +setEIP1559Params +eip1559Elasticity +eip1559Denominator -OptimismPortal - -Interface - -setConfig @@ -9405,23 +9134,7 @@ Configurabili Overview -The SystemConfig and OptimismPortal are updated with a new flow for chain -configurability. -Constants -ConfigType -The ConfigType enum represents configuration that can be modified. -NameValueDescription -SET_GAS_PAYING_TOKENuint8(0)Modifies the gas paying token for the chain -SET_BASE_FEE_VAULT_CONFIGuint8(1)Sets the Fee Vault Config for the BaseFeeVault -SET_L1_FEE_VAULT_CONFIGuint8(2)Sets the Fee Vault Config for the L1FeeVault -SET_SEQUENCER_FEE_VAULT_CONFIGuint8(3)Sets the Fee Vault Config for the SequencerFeeVault -SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESSuint8(4)Sets the L1CrossDomainMessenger address -SET_L1_ERC_721_BRIDGE_ADDRESSuint8(5)Sets the L1ERC721Bridge address -SET_L1_STANDARD_BRIDGE_ADDRESSuint8(6)Sets the L1StandardBridge address -SET_REMOTE_CHAIN_IDuint8(7)Sets the chain id of the base chain - - -SystemConfig +The SystemConfig is updated to allow for dynamic EIP-1559 parameters. ConfigUpdate The following ConfigUpdate event is defined where the CONFIG_VERSION is uint256(0): NameValueDefinitionUsage @@ -9440,21 +9153,12 @@ Initialization< emit ConfigUpdate.GAS_LIMIT emit ConfigUpdate.UNSAFE_BLOCK_SIGNER emit ConfigUpdate.EIP_1559_PARAMS -setConfig(SET_GAS_PAYING_TOKEN) -setConfig(SET_BASE_FEE_VAULT_CONFIG) -setConfig(SET_L1_FEE_VAULT_CONFIG) -setConfig(SET_SEQUENCER_FEE_VAULT_CONFIG) -setConfig(SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESS) -setConfig(SET_L1_ERC_721_BRIDGE_ADDRESS) -setConfig(SET_L1_STANDARD_BRIDGE_ADDRESS) -setConfig(SET_REMOTE_CHAIN_ID) - -These actions MAY only be triggered if there is a diff to the value. + Modifying EIP-1559 Parameters A new SystemConfig UpdateType is introduced that enables the modification of EIP-1559 parameters. This allows for the chain operator to modify the BASE_FEE_MAX_CHANGE_DENOMINATOR and the ELASTICITY_MULTIPLIER. -Interface +Interface EIP-1559 Params setEIP1559Params This function MUST only be callable by the chain governor. @@ -9470,39 +9174,6 @@ e This function returns the currently configured EIP-1559 denominator. function eip1559Denominator()(uint64) -Fee Vault Config -For each FeeVault, there is a setter for its config. The arguments to the setter include -the RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork. -Each of these functions should be public and only callable by the chain governor. -Each function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType. -setBaseFeeVaultConfig -function setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork) - -setL1FeeVaultConfig -function setL1FeeVaultConfig(address,uint256,WithdrawalNetwork) - -setSequencerFeeVaultConfig -function setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork) - -OptimismPortal -The OptimismPortal is updated to emit a special system TransactionDeposited event. -Interface -setConfig -The setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig -is the single source of truth for chain operator ownership. -function setConfig(ConfigType,bytes) - -This function emits a TransactionDeposited event. -event TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData); - -The following fields are included: - -from is the DEPOSITOR_ACCOUNT -to is Predeploys.L1Block -version is uint256(0) -opaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit -is 200_000, isCreation is false and the data is abi.encodeCall(L1Block.setConfig, (_type, _value)) - Governance Token @@ -9670,7 +9341,7 @@ Overview The terms "custom gas token", "gas paying token", "native asset" and "gas paying asset" can all be used interchangeably. Note, Ether is not a custom gas token, but may be used to pay gas. More on this in Configuring the Gas Paying Token. -Constants +Constants ConstantValueDescription ETHER_TOKEN_ADDRESSaddress(0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE)Represents ether for gas paying asset DEPOSITOR_ACCOUNTaddress(0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001)Account with auth permissions on L1Block contract @@ -9766,7 +9437,7 @@ Gas Token Awa L2CrossDomainMessenger OptimismPortal -OptimismPortal +OptimismPortal The OptimismPortal is updated with a new interface specifically for depositing custom tokens. depositERC20Transaction The depositERC20Transaction function is useful for sending custom gas tokens to L2. It is broken out into its @@ -9848,7 +9519,7 @@ Cro The L1CrossDomainMessenger fetches this tuple from the SystemConfig contract. The L2CrossDomainMessenger fetches this tuple from the L1Block contract. -SystemConfig +SystemConfig The SystemConfig is the source of truth for the address of the custom gas token. It does on chain validation, stores information about the token and well as passes the information to L2. initialize @@ -9860,7 +9531,7 @@ initialize symbol MUST be less than or equal to 32 bytes. If the token passes all of these checks, OptimismPortal.setGasPayingToken is called. The implementation of initialize MUST not allow the chain operator to change the address of the custom gas token if it is already set. -L1Block +L1Block The L1Block contract is upgraded with a permissioned function setGasPayingToken that is used to set information about the gas paying token. The DEPOSITOR_ACCOUNT MUST be the only account that can call the setter function. This setter is differentiated from the setL1BlockValues functions because the gas paying @@ -10019,7 +9690,7 @@ Fees blobbasefee. When a custom gas token is used, fees are paid in the custom gas token but the conversion rate to ether is not taken into account as part of the protocol. It is assumed that the fees will be configured by the chain operator such that the revenue earned in custom gas token can be swapped into ether to pay for posting the data to L1. -Security Considerations +Security Considerations OptimismPortal Token Allowance The OptimismPortal makes calls on behalf of users. It is therefore unsafe to be able to call the address of the custom gas token itself from the OptimismPortal because it would be a simple way to approve an attacker's @@ -10287,7 +9958,7 @@ Safet that an L2 block is derived from becomes finalized, the L2 block can be marked as finalized. The engine queue will maintain a longer buffer of L2 blocks waiting for the DA window to expire and the L1 block with the commitment to be finalized in order to signal finality. -Security Considerations +Security Considerations The Data Availability Challenge contract mitigates DoS vulnerability with a payable bond requirement making challenging the availability of a commitment at least as expensive as submitting the data onchain to resolve the challenge. @@ -10387,7 +10058,7 @@ Security Considerations +Security Considerations Layer 1 as Part of the Dependency Set The layer one MAY be part of the dependency set if the fault proof implementation is set up to support it. It is known that it is possible but it is not known if this is going to be @@ -10603,7 +10274,7 @@ Boundin Every block cannot depend on expired messages, as per the Message expiry invariant. The verifier is responsible for filtering out non-canonical parts of the graph. -Security Considerations +Security Considerations Cyclic dependencies If there is a cycle in the dependency set, chains MUST still be able to promote unsafe blocks to safe blocks. A cycle in the dependency set happens anytime that two chains are in each other's @@ -11126,7 +10797,7 @@ Overview The Beacon Contract implements the interface defined in EIP-1967. The implementation address gets deduced similarly to the GasPriceOracle address in Ecotone and Fjord updates. -L1Block +L1Block ConstantValue Address0x4200000000000000000000000000000000000015 DEPOSITOR_ACCOUNT0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 @@ -11253,7 +10924,7 @@ event StandardL2TokenCreated(address indexed remoteToken, address indexed localToken); -L2StandardBridge +L2StandardBridge ConstantValue Address0x4200000000000000000000000000000000000010 @@ -11436,7 +11107,7 @@ Invariants -Security Considerations +Security Considerations TODO Sequencer @@ -11561,7 +11232,7 @@ Sponsorship If a user does not have ether to pay for the gas of an executing message, application layer sponsorship solutions can be created. It is possible to create an MEV incentive by paying tx.origin in the executing message. This can be done by wrapping the L2ToL2CrossDomainMessenger with a pair of relaying contracts. -Security Considerations +Security Considerations Cross Chain Message Latency The latency at which a cross chain message is relayed from the moment at which it was initiated is bottlenecked by the security of the preconfirmations. An initiating transaction and a executing transaction MAY have the same timestamp, @@ -11699,7 +11370,7 @@ Honest Verifi follows. The main difference is that the validity of included executing messages is verified instead of verifying possible executing messages before inclusion. -Security Considerations +Security Considerations Forced Inclusion of Cross Chain Messages The design is particular to not introduce any sort of "forced inclusion" between L2s. This design space introduces risky synchrony assumptions and forces the introduction of a message queue to prevent denial of service attacks where @@ -11739,7 +11410,7 @@ P2P Networking< sets of executing messages to nodes of remote chains so that they know exactly what initiating messages to look for. An optimization on this would involve working with commitments to this data so that less data is sent around via p2p. -Security Considerations +Security Considerations TODO Fault Proof @@ -11761,7 +11432,7 @@ No changes to the dispute game bisection are required. The only changes required are to the fault proof program itself. The insight is that the fault proof program can be a superset of the state transition function. -Security Considerations +Security Considerations TODO Interop Network Upgrade @@ -11839,7 +11510,7 @@ L1 Attributes Deposited Transaction Calldata. -Security Considerations +Security Considerations TODO Token Bridging @@ -11899,7 +11570,7 @@ Properties Notice that ERC20s that do not implement the standard can still be fungible using interop message passing using a custom bridge or implementing sendERC20 and relayERC20 on their own contracts. -Interface +Interface Implementations of the SuperchainERC20 standard will need to implement two external functions and two events: __superchainMint Mints _amount of token to address _account. It should only be callable by the SuperchainERC20Bridge @@ -12098,7 +11769,7 @@ Constants +Constants NameValue SuperchainWETH Address0x4200000000000000000000000000000000000024 ETHLiquidity Address0x4200000000000000000000000000000000000025 @@ -12266,7 +11937,7 @@ Security Considerations +Security Considerations Gas Considerations There must be sufficient gas available in the block to destroy deposit context. There's no guarantee on the minimum gas available for the second L1 attributes transaction as the block @@ -12330,7 +12001,7 @@ Security Considerations +Security Considerations Mempool Denial of Service Since the validation of the executing message relies on a remote RPC request, this introduces a denial of service attack vector. The cost of network access is magnitudes larger than in memory validity checks. @@ -12378,8 +12049,8 @@ OP Deployment The OP Contracts Manager is a proxied contract deployed at 0xTODO. It can be deployed as follows: TODO. -Interface -Version 1.0.0 of the OP Contracts Manager deploys the [op-contracts/v1.6.0] +Interface +Version 1.0.0 of the OP Contracts Manager deploys the op-contracts/v1.6.0 contracts release. Proxy.sol The OP Contracts Manager is a proxied contract using the standard Proxy.sol contract that lives in @@ -12478,7 +12149,7 @@ Con -Security Considerations +Security Considerations Chain ID Source of Truth One of the implicit restrictions on chain ID is that deploy can only be called once per chain ID, because contract addresses are a function of chain ID. However, diff --git a/protocol/batcher.html b/protocol/batcher.html index 3b2dd42f6..b43477961 100644 --- a/protocol/batcher.html +++ b/protocol/batcher.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/bridges.html b/protocol/bridges.html index 82d8153b0..78ccebfed 100644 --- a/protocol/bridges.html +++ b/protocol/bridges.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/canyon/overview.html b/protocol/canyon/overview.html index 6676f930a..60f52a8c2 100644 --- a/protocol/canyon/overview.html +++ b/protocol/canyon/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/configurability.html b/protocol/configurability.html index 79b184b12..8cf628d3c 100644 --- a/protocol/configurability.html +++ b/protocol/configurability.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/delta/overview.html b/protocol/delta/overview.html index a3601d0d5..359a3d161 100644 --- a/protocol/delta/overview.html +++ b/protocol/delta/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/delta/span-batches.html b/protocol/delta/span-batches.html index 3232dddcf..b9de7318b 100644 --- a/protocol/delta/span-batches.html +++ b/protocol/delta/span-batches.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/deposits.html b/protocol/deposits.html index 2e8b7b28a..9edf1b72d 100644 --- a/protocol/deposits.html +++ b/protocol/deposits.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/derivation.html b/protocol/derivation.html index f67e22c5e..b84e7f620 100644 --- a/protocol/derivation.html +++ b/protocol/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/derivation.html b/protocol/ecotone/derivation.html index 69f48b18d..48edf5eae 100644 --- a/protocol/ecotone/derivation.html +++ b/protocol/ecotone/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/l1-attributes.html b/protocol/ecotone/l1-attributes.html index 94c9a9abb..fdba52917 100644 --- a/protocol/ecotone/l1-attributes.html +++ b/protocol/ecotone/l1-attributes.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/overview.html b/protocol/ecotone/overview.html index ffb372c15..d95d00c2b 100644 --- a/protocol/ecotone/overview.html +++ b/protocol/ecotone/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/exec-engine.html b/protocol/exec-engine.html index a994871cc..115393699 100644 --- a/protocol/exec-engine.html +++ b/protocol/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/derivation.html b/protocol/fjord/derivation.html index 344bdbaf3..0a1ae0b01 100644 --- a/protocol/fjord/derivation.html +++ b/protocol/fjord/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/exec-engine.html b/protocol/fjord/exec-engine.html index 01d2281fd..69cb1bc77 100644 --- a/protocol/fjord/exec-engine.html +++ b/protocol/fjord/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/overview.html b/protocol/fjord/overview.html index 783db2fbb..30f1c440c 100644 --- a/protocol/fjord/overview.html +++ b/protocol/fjord/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/predeploys.html b/protocol/fjord/predeploys.html index bae67eae6..d46e6398f 100644 --- a/protocol/fjord/predeploys.html +++ b/protocol/fjord/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/derivation.html b/protocol/granite/derivation.html index e9d88dbae..e19cba517 100644 --- a/protocol/granite/derivation.html +++ b/protocol/granite/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/exec-engine.html b/protocol/granite/exec-engine.html index 8c0f1e46d..684d3fb06 100644 --- a/protocol/granite/exec-engine.html +++ b/protocol/granite/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/overview.html b/protocol/granite/overview.html index 7b5492827..bb2905a4a 100644 --- a/protocol/granite/overview.html +++ b/protocol/granite/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/guaranteed-gas-market.html b/protocol/guaranteed-gas-market.html index c42c12354..863931f80 100644 --- a/protocol/guaranteed-gas-market.html +++ b/protocol/guaranteed-gas-market.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/holocene/derivation.html b/protocol/holocene/derivation.html index f1eea3faf..c38652a86 100644 --- a/protocol/holocene/derivation.html +++ b/protocol/holocene/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/holocene/exec-engine.html b/protocol/holocene/exec-engine.html index d44a82f56..4253e4082 100644 --- a/protocol/holocene/exec-engine.html +++ b/protocol/holocene/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -194,81 +194,36 @@ L2 Ex Table of Contents +Overview Timestamp Activation -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters -Header Validity Rules -Header Withdrawals Root - -Rationale -Forwards Compatibility Considerations -Client Implementation Considerations - - - - Extended PayloadAttributesV3 eip1559Params encoding -Execution -Rationale +Execution +Rationale eip1559Params in Header -Header Validity Rules +Header Validity Rules Encoding -Rationale +Rationale + + +Overview +The EIP-1559 parameters are encoded in the block header's nonce field and can be +configured dynamically through the SystemConfig. Timestamp Activation Holocene, like other network upgrades, is activated at a timestamp. Changes to the L2 Block execution rules are applied when the L2 Timestamp >= activation time. -L2ToL1MessagePasser Storage Root in Header -After Holocene's activation, the L2 block header's withdrawalsRoot field will consist of the 32-byte -L2ToL1MessagePasser account storage root after the block has been executed, and after the -insertions and deletions have been applied to the trie. In other words, the storage root should be the same root -that is returned by eth_getProof at the given block number. -Header Validity Rules -Prior to holocene activation, the L2 block header's withdrawalsRoot field must be: - -nil if Canyon has not been activated. -keccak256(rlp(empty_string_code)) if Canyon has been activated. - -After Holocene activation, an L2 block header's withdrawalsRoot field is valid iff: - -It is exactly 32 bytes in length. -The L2ToL1MessagePasser account storage root, as committed to in the storageRoot within the block -header, is equal to the header's withdrawalsRoot field. - -Header Withdrawals Root -Byte offsetDescription -[0, 32)L2ToL1MessagePasser account storage root - - -Rationale -Currently, to generate L2 output roots for historical blocks, an archival node is required. This directly -places a burden on users of the system in a post-fault-proofs world, where: - -A proposer must have an archive node to propose an output root at the safe head. -A user that is proving their withdrawal must have an archive node to verify that the output root they are proving -their withdrawal against is indeed valid and included within the safe chain. - -Placing the L2ToL1MessagePasser account storage root in the withdrawalsRoot field alleviates this burden -for users and protocol participants alike, allowing them to propose and verify other proposals with lower operating costs. -Forwards Compatibility Considerations -As it stands, the withdrawalsRoot field is unused within the OP Stack's header consensus format, and will never be -used for other reasons that are currently planned. Setting this value to the account storage root of the withdrawal -directly fits with the OP Stack, and makes use of the existing field in the L1 header consensus format. -Client Implementation Considerations -Varous EL clients store historical state of accounts differently. If, as a contrived case, an OP Stack chain did not have -an outbound withdrawal for a long period of time, the node may not have access to the account storage root of the -L2ToL1MessagePasser. In this case, the client would be unable to keep consensus. However, most modern -clients are able to at the very least reconstruct the account storage root at a given block on the fly if it does not -directly store this information. -Extended PayloadAttributesV3 +Dynamic EIP-1559 Parameters +Extended PayloadAttributesV3 The PayloadAttributesV3 type is extended to: PayloadAttributesV3: { @@ -283,7 +238,7 @@ eip1559Params encoding +eip1559Params encoding NameTypeByte Offset denominatoru32 (big-endian)[0, 4) elasticityu32 (big-endian)[4, 8) @@ -303,19 +258,19 @@ Execution -Rationale +Rationale This type is made available in the payload attributes to allow the block builder to dynamically control the EIP-1559 parameters of the chain. As described in the derivation - AttributesBuilder section, the derivation pipeline must populate this field from the SystemConfig during payload building, similar to how it must reference the SystemConfig for the gasLimit field. -eip1559Params in Header +eip1559Params in Header Upon Holocene activation, the L2 block header's nonce field will consist of the 8-byte eip1559Params value. -Header Validity Rules +Header Validity Rules Prior to Holocene activation, the L2 block header's nonce field is valid iff it is equal to u64(0). After Holocene activation, The L2 block header's nonce field is valid iff it is non-zero. -Encoding +Encoding The encoding of the eip1559Params value is described in eip1559Params encoding. -Rationale +Rationale By chosing to put the eip1559Params in the PayloadAttributes rather than in the L1 block info transaction, the EIP-1559 parameters for the chain are not available within history. This would place a burden on performing historical execution, as L1 would have to be consulted for fetching the values from the SystemConfig contract. diff --git a/protocol/holocene/overview.html b/protocol/holocene/overview.html index 0ce159035..1714698a1 100644 --- a/protocol/holocene/overview.html +++ b/protocol/holocene/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -199,10 +199,9 @@ Smart Contracts -This document is not finalized and should be considered experimental. Execution Layer -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters Consensus Layer @@ -210,8 +209,7 @@ Consensus Lay Smart Contracts -Predeploys -Configurability +System Config diff --git a/protocol/holocene/predeploys.html b/protocol/holocene/predeploys.html index 3c4f9c31d..3c6067ec3 100644 --- a/protocol/holocene/predeploys.html +++ b/protocol/holocene/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -189,209 +189,7 @@ OP Stack Specification -Overview - - -Table of Contents - -Constants -Predeploys - -L1Block - -Storage -Interface - -setHolocene -setConfig -baseFeeVaultConfig -sequencerFeeVaultConfig -l1FeeVaultConfig -l1CrossDomainMessenger -l1StandardBridge -l1ERC721Bridge -remoteChainId - - - - -FeeVault - -Interface - -config - - - - -L2CrossDomainMessenger - -Interface - - -L2ERC721Bridge - -Interface - - -L2StandardBridge - -Interface - - -OptimismMintableERC721Factory - - -Security Considerations - -GovernanceToken - - - - -This upgrade enables a deterministic L2 genesis state by moving all network -specific configuration out of the initial L2 genesis state. All network specific -configuration is sourced from deposit transactions during the initialization -of the SystemConfig. -Constants -NameValueDefinition -ConfigTypeuint8An enum representing the type of config being set -WithdrawalNetworkuint8(0) or uint8(1)0 means withdraw to L1, 1 means withdraw to L2 -RECIPIENTaddressThe account that will receive funds sent out of the FeeVault -MIN_WITHDRAWAL_AMOUNTuint256The minimum amount of native asset held in the FeeVault before withdrawal is authorized -Fee Vault Configbytes32bytes32((WithdrawalNetwork << 248) || uint256(uint88(MIN_WITHDRAWAL_AMOUNT)) || uint256(uint160(RECIPIENT))) -BASE_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.basefeevaultconfig")) - 1)The Fee Vault Config for the BaseFeeVault -L1_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.l1feevaultconfig")) - 1)The Fee Vault Config for the L1FeeVault -SEQUENCER_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.sequencerfeevaultconfig")) - 1)The Fee Vault Config for the SequencerFeeVault -L1_CROSS_DOMAIN_MESSENGER_ADDRESSbytes32(uint256(keccak256("opstack.l1crossdomainmessengeraddress")) - 1)abi.encode(address(L1CrossDomainMessengerProxy)) -L1_ERC_721_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1erc721bridgeaddress")) - 1)abi.encode(address(L1ERC721BridgeProxy)) -L1_STANDARD_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1standardbridgeaddress")) - 1)abi.encode(address(L1StandardBridgeProxy)) -REMOTE_CHAIN_IDbytes32(uint256(keccak256("opstack.remotechainid")) - 1)Chain ID of the remote chain - - -Predeploys -All network specific configuration is moved to a single contract, the L1Block predeploy. -All predeploys make calls to the L1Block contract to fetch network specific configuration -rather than reading it from local state. -graph LR - subgraph L1 - SystemConfig -- "setConfig(uint8,bytes)" --> OptimismPortal - end - subgraph L2 - L1Block - BaseFeeVault -- "baseFeeVaultConfig()(address,uint256,uint8)" --> L1Block - SequencerFeeVault -- "sequencerFeeVaultConfig()(address,uint256,uint8)" --> L1Block - L1FeeVault -- "l1FeeVaultConfig()(address,uint256,uint8)" --> L1Block - L2CrossDomainMessenger -- "l1CrossDomainMessenger()(address)" --> L1Block - L2StandardBridge -- "l1StandardBridge()(address)" --> L1Block - L2ERC721Bridge -- "l1ERC721Bridge()(address)" --> L1Block - OptimismMintableERC721Factory -- "remoteChainId()(uint256)" --> L1Block - end - OptimismPortal -- "setConfig(uint8,bytes)" --> L1Block - -L1Block -Storage -The following storage slots are defined: - -BASE_FEE_VAULT_CONFIG -L1_FEE_VAULT_CONFIG -SEQUENCER_FEE_VAULT_CONFIG -L1_CROSS_DOMAIN_MESSENGER_ADDRESS -L1_ERC_721_BRIDGE_ADDRESS -L1_STANDARD_BRIDGE_ADDRESS -REMOTE_CHAIN_ID - -Each slot MUST have a defined ConfigType that authorizes the setting of the storage slot -via a deposit transaction from the DEPOSITOR_ACCOUNT. -Interface -setHolocene -This function is meant to be called once on the activation block of the holocene network upgrade. -It MUST only be callable by the DEPOSITOR_ACCOUNT once. When it is called, it MUST call -call each getter for the network specific config and set the returndata into storage. -setConfig -This function MUST only be callable by the DEPOSITOR_ACCOUNT. It modifies the storage directly -of the L1Block contract. It MUST handle all defined ConfigTypes. To ensure a simple ABI, the -bytes value MUST be abi decoded based on the ConfigType. -function setConfig(ConfigType,bytes) - -Note that ConfigType is an enum which is an alias for a uint8. -baseFeeVaultConfig -This function MUST be called by the BaseFeeVault to fetch network specific configuration. -function baseFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -sequencerFeeVaultConfig -This function MUST be called by the SequencerFeeVault to fetch network specific configuration. -function sequencerFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1FeeVaultConfig -This function MUST be called by the L1FeeVault to fetch network specific configuration. -function l1FeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1CrossDomainMessenger -This function MUST be called by the L2CrossDomainMessenger to fetch the address of the L1CrossDomainMessenger. -function l1CrossDomainMessenger()(address) - -l1StandardBridge -This function MUST be called by the L2StandardBridge to fetch the address of the L2CrossDomainMessenger. -function l1StandardBridge()(address) - -l1ERC721Bridge -This function MUST be called by the L2ERC721Bridge to fetch the address of the L1ERC721Bridge. -function l1ERC721Bridge()(address) - -remoteChainId -This function MUST be called by the OptimismMintableERC721Factory to fetch the chain id of the remote chain. -For an L2, this is the L1 chain id. -function remoteChainId()(uint256) - -FeeVault -The following changes apply to each of the BaseFeeVault, the L1FeeVault and the SequencerFeeVault. -Interface -The following functions are updated to read from the L1Block contract: - -recipient()(address) -withdrawalNetwork()(WithdrawalNetwork) -minWithdrawalAmount()(uint256) -withdraw() - -NameCall -BaseFeeVaultL1Block.baseFeeVaultConfig() -SequencerFeeVaultL1Block.sequencerFeeVaultConfig() -L1FeeVaultL1Block.l1FeeVaultConfig() - - -config -A new function is added to fetch the full Fee Vault Config. -function config()(address,uint256,WithdrawalNetwork) - -L2CrossDomainMessenger -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1CrossDomainMessenger(): - -otherMessenger()(address) -OTHER_MESSENGER()(address) - -L2ERC721Bridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1ERC721Bridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -L2StandardBridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1StandardBridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -OptimismMintableERC721Factory -The chain id is no longer read from storage but instead is read from the L1Block contract by calling -L1Block.remoteChainId() -Security Considerations -GovernanceToken -The predeploy defined by GovernanceToken should be an empty account until it is defined by -a future hardfork. +Predeploys @@ -401,7 +199,7 @@ GovernanceTok - + @@ -415,7 +213,7 @@ GovernanceTok - + diff --git a/protocol/holocene/configurability.html b/protocol/holocene/system-config.html similarity index 72% rename from protocol/holocene/configurability.html rename to protocol/holocene/system-config.html index 985283b56..0df792e3e 100644 --- a/protocol/holocene/configurability.html +++ b/protocol/holocene/system-config.html @@ -3,7 +3,7 @@ - Configurability - OP Stack Specification + System Config - OP Stack Specification @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -159,7 +159,7 @@ OP Stack Specification - + @@ -189,18 +189,12 @@ OP Stack Specification -Configurability +System Config Table of Contents -Overview -Constants - -ConfigType - - -SystemConfig +Overview ConfigUpdate Initialization @@ -214,22 +208,6 @@ Configurabili eip1559Denominator -Fee Vault Config - -setBaseFeeVaultConfig -setL1FeeVaultConfig -setSequencerFeeVaultConfig - - - - - - -OptimismPortal - -Interface - -setConfig @@ -237,23 +215,7 @@ Configurabili Overview -The SystemConfig and OptimismPortal are updated with a new flow for chain -configurability. -Constants -ConfigType -The ConfigType enum represents configuration that can be modified. -NameValueDescription -SET_GAS_PAYING_TOKENuint8(0)Modifies the gas paying token for the chain -SET_BASE_FEE_VAULT_CONFIGuint8(1)Sets the Fee Vault Config for the BaseFeeVault -SET_L1_FEE_VAULT_CONFIGuint8(2)Sets the Fee Vault Config for the L1FeeVault -SET_SEQUENCER_FEE_VAULT_CONFIGuint8(3)Sets the Fee Vault Config for the SequencerFeeVault -SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESSuint8(4)Sets the L1CrossDomainMessenger address -SET_L1_ERC_721_BRIDGE_ADDRESSuint8(5)Sets the L1ERC721Bridge address -SET_L1_STANDARD_BRIDGE_ADDRESSuint8(6)Sets the L1StandardBridge address -SET_REMOTE_CHAIN_IDuint8(7)Sets the chain id of the base chain - - -SystemConfig +The SystemConfig is updated to allow for dynamic EIP-1559 parameters. ConfigUpdate The following ConfigUpdate event is defined where the CONFIG_VERSION is uint256(0): NameValueDefinitionUsage @@ -272,16 +234,7 @@ Initialization< emit ConfigUpdate.GAS_LIMIT emit ConfigUpdate.UNSAFE_BLOCK_SIGNER emit ConfigUpdate.EIP_1559_PARAMS -setConfig(SET_GAS_PAYING_TOKEN) -setConfig(SET_BASE_FEE_VAULT_CONFIG) -setConfig(SET_L1_FEE_VAULT_CONFIG) -setConfig(SET_SEQUENCER_FEE_VAULT_CONFIG) -setConfig(SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESS) -setConfig(SET_L1_ERC_721_BRIDGE_ADDRESS) -setConfig(SET_L1_STANDARD_BRIDGE_ADDRESS) -setConfig(SET_REMOTE_CHAIN_ID) -These actions MAY only be triggered if there is a diff to the value. Modifying EIP-1559 Parameters A new SystemConfig UpdateType is introduced that enables the modification of EIP-1559 parameters. This allows for the chain @@ -302,39 +255,6 @@ e This function returns the currently configured EIP-1559 denominator. function eip1559Denominator()(uint64) -Fee Vault Config -For each FeeVault, there is a setter for its config. The arguments to the setter include -the RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork. -Each of these functions should be public and only callable by the chain governor. -Each function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType. -setBaseFeeVaultConfig -function setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork) - -setL1FeeVaultConfig -function setL1FeeVaultConfig(address,uint256,WithdrawalNetwork) - -setSequencerFeeVaultConfig -function setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork) - -OptimismPortal -The OptimismPortal is updated to emit a special system TransactionDeposited event. -Interface -setConfig -The setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig -is the single source of truth for chain operator ownership. -function setConfig(ConfigType,bytes) - -This function emits a TransactionDeposited event. -event TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData); - -The following fields are included: - -from is the DEPOSITOR_ACCOUNT -to is Predeploys.L1Block -version is uint256(0) -opaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit -is 200_000, isCreation is false and the data is abi.encodeCall(L1Block.setConfig, (_type, _value)) - diff --git a/protocol/messengers.html b/protocol/messengers.html index 5719b0eac..b0c6745a4 100644 --- a/protocol/messengers.html +++ b/protocol/messengers.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/overview.html b/protocol/overview.html index 19a171b6b..8d974911d 100644 --- a/protocol/overview.html +++ b/protocol/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/precompiles.html b/protocol/precompiles.html index 2636bcded..591225781 100644 --- a/protocol/precompiles.html +++ b/protocol/precompiles.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/predeploys.html b/protocol/predeploys.html index f69344d63..18f80ecc9 100644 --- a/protocol/predeploys.html +++ b/protocol/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/preinstalls.html b/protocol/preinstalls.html index a3e678702..de25cd1f4 100644 --- a/protocol/preinstalls.html +++ b/protocol/preinstalls.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/proposals.html b/protocol/proposals.html index 4356aed7b..c7e27aba0 100644 --- a/protocol/proposals.html +++ b/protocol/proposals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/regolith/overview.html b/protocol/regolith/overview.html index 25fb28a59..735c8d392 100644 --- a/protocol/regolith/overview.html +++ b/protocol/regolith/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node-p2p.html b/protocol/rollup-node-p2p.html index 6b7b877ad..f733fce32 100644 --- a/protocol/rollup-node-p2p.html +++ b/protocol/rollup-node-p2p.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node.html b/protocol/rollup-node.html index 7b2194855..74e7465df 100644 --- a/protocol/rollup-node.html +++ b/protocol/rollup-node.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/safe-extensions.html b/protocol/safe-extensions.html index c13615619..4601198ba 100644 --- a/protocol/safe-extensions.html +++ b/protocol/safe-extensions.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/stage-1.html b/protocol/stage-1.html index d28f06461..2659aa26c 100644 --- a/protocol/stage-1.html +++ b/protocol/stage-1.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-configuration.html b/protocol/superchain-configuration.html index ee7a3f560..6796bb40e 100644 --- a/protocol/superchain-configuration.html +++ b/protocol/superchain-configuration.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-upgrades.html b/protocol/superchain-upgrades.html index e9ac90b28..aad45a9b2 100644 --- a/protocol/superchain-upgrades.html +++ b/protocol/superchain-upgrades.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/system-config.html b/protocol/system-config.html index afbdefd92..d5fe843f1 100644 --- a/protocol/system-config.html +++ b/protocol/system-config.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/withdrawals.html b/protocol/withdrawals.html index e390c5450..8596661a9 100644 --- a/protocol/withdrawals.html +++ b/protocol/withdrawals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/root.html b/root.html index 20d712d67..bd978d50b 100644 --- a/root.html +++ b/root.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/searchindex.js b/searchindex.js index 371b06267..623744500 100644 --- a/searchindex.js +++ b/searchindex.js @@ -1 +1 @@ -Object.assign(window.search, {"doc_urls":["root.html#op-stack-specification","root.html#about-optimism","root.html#about-the-op-stack","root.html#site-navigation","background.html#background","background.html#overview","background.html#foundations","background.html#ethereum-scalability","background.html#optimistic-rollups","background.html#evm-equivalence","background.html#protocol-guarantees","background.html#liveness","background.html#validity","background.html#availability","background.html#network-participants","background.html#users","background.html#sequencers","background.html#verifiers","background.html#key-interaction-diagrams","background.html#depositing-and-sending-transactions","background.html#withdrawing","background.html#next-steps","protocol/overview.html#optimism-overview","protocol/overview.html#architecture-design-goals","protocol/overview.html#architecture-overview","protocol/overview.html#core-l1-smart-contracts","protocol/overview.html#core-l2-smart-contracts","protocol/overview.html#smart-contract-proxies","protocol/overview.html#l2-node-components","protocol/overview.html#transactionblock-propagation","protocol/overview.html#key-interactions-in-depth","protocol/overview.html#deposits","protocol/overview.html#block-derivation","protocol/overview.html#engine-api","protocol/bridges.html#standard-bridges","protocol/bridges.html#overview","protocol/bridges.html#token-depositing","protocol/bridges.html#upgradability","protocol/messengers.html#cross-domain-messengers","protocol/messengers.html#overview","protocol/messengers.html#message-passing","protocol/messengers.html#upgradability","protocol/messengers.html#message-versioning","protocol/messengers.html#message-version-0","protocol/messengers.html#message-version-1","protocol/messengers.html#backwards-compatibility-notes","protocol/deposits.html#deposits","protocol/deposits.html#overview","protocol/deposits.html#the-deposited-transaction-type","protocol/deposits.html#source-hash-computation","protocol/deposits.html#kinds-of-deposited-transactions","protocol/deposits.html#validation-and-authorization-of-deposited-transactions","protocol/deposits.html#execution","protocol/deposits.html#deposit-receipt","protocol/deposits.html#l1-attributes-deposited-transaction","protocol/deposits.html#l1-attributes-deposited-transaction-calldata","protocol/deposits.html#special-accounts-on-l2","protocol/deposits.html#l1-attributes-depositor-account","protocol/deposits.html#l1-attributes-predeployed-contract","protocol/deposits.html#user-deposited-transactions","protocol/deposits.html#deposit-contract","protocol/withdrawals.html#withdrawals","protocol/withdrawals.html#overview","protocol/withdrawals.html#withdrawal-flow","protocol/withdrawals.html#on-l2","protocol/withdrawals.html#on-l1","protocol/withdrawals.html#the-l2tol1messagepasser-contract","protocol/withdrawals.html#addresses-are-not-aliased-on-withdrawals","protocol/withdrawals.html#the-optimism-portal-contract","protocol/withdrawals.html#withdrawal-verification-and-finalization","protocol/withdrawals.html#security-considerations","protocol/withdrawals.html#key-properties-of-withdrawal-verification","protocol/withdrawals.html#handling-successfully-verified-messages-that-fail-when-relayed","protocol/withdrawals.html#optimismportal-can-send-arbitrary-messages-on-l1","protocol/guaranteed-gas-market.html#guaranteed-gas-fee-market","protocol/guaranteed-gas-market.html#overview","protocol/guaranteed-gas-market.html#gas-stipend","protocol/guaranteed-gas-market.html#default-values","protocol/guaranteed-gas-market.html#limiting-guaranteed-gas","protocol/guaranteed-gas-market.html#rationale-for-burning-l1-gas","protocol/guaranteed-gas-market.html#on-preventing-griefing-attacks","protocol/proposals.html#l2-output-root-proposals-specification","protocol/proposals.html#overview","protocol/proposals.html#proposing-l2-output-commitments","protocol/proposals.html#l2outputoracle-v100","protocol/proposals.html#l2-output-commitment-construction","protocol/proposals.html#l2-output-oracle-smart-contract","protocol/proposals.html#configuration","protocol/proposals.html#security-considerations","protocol/proposals.html#l1-reorgs","protocol/exec-engine.html#l2-execution-engine","protocol/exec-engine.html#1559-parameters","protocol/exec-engine.html#deposited-transaction-processing","protocol/exec-engine.html#deposited-transaction-boundaries","protocol/exec-engine.html#fees","protocol/exec-engine.html#fee-vaults","protocol/exec-engine.html#priority-fees-sequencer-fee-vault","protocol/exec-engine.html#base-fees-base-fee-vault","protocol/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/exec-engine.html#engine-api","protocol/exec-engine.html#engine_forkchoiceupdatedv2","protocol/exec-engine.html#engine_forkchoiceupdatedv3","protocol/exec-engine.html#engine_newpayloadv2","protocol/exec-engine.html#engine_newpayloadv3","protocol/exec-engine.html#engine_getpayloadv2","protocol/exec-engine.html#engine_getpayloadv3","protocol/exec-engine.html#engine_signalsuperchainv1","protocol/exec-engine.html#networking","protocol/exec-engine.html#sync","protocol/exec-engine.html#happy-path-sync","protocol/exec-engine.html#worst-case-sync","protocol/exec-engine.html#ecotone-disable-blob-transactions","protocol/exec-engine.html#ecotone-beacon-block-root","protocol/exec-engine.html#p2p-modifications","protocol/rollup-node.html#rollup-node-specification","protocol/rollup-node.html#overview","protocol/rollup-node.html#driver","protocol/rollup-node.html#derivation","protocol/rollup-node.html#l2-output-rpc-method","protocol/rollup-node.html#structures","protocol/rollup-node.html#output-method-api","protocol/rollup-node.html#protocol-version-tracking","protocol/rollup-node-p2p.html#rollup-node-p2p-interface","protocol/rollup-node-p2p.html#overview","protocol/rollup-node-p2p.html#p2p-configuration","protocol/rollup-node-p2p.html#identification","protocol/rollup-node-p2p.html#discv5","protocol/rollup-node-p2p.html#libp2p","protocol/rollup-node-p2p.html#gossip-topics","protocol/rollup-node-p2p.html#blocksv1","protocol/rollup-node-p2p.html#blocksv2","protocol/rollup-node-p2p.html#blocksv3","protocol/rollup-node-p2p.html#block-encoding","protocol/rollup-node-p2p.html#block-signatures","protocol/rollup-node-p2p.html#block-validation","protocol/rollup-node-p2p.html#req-resp","protocol/rollup-node-p2p.html#payload_by_number","protocol/derivation.html#l2-chain-derivation-specification","protocol/derivation.html#overview","protocol/derivation.html#eager-block-derivation","protocol/derivation.html#protocol-parameters","protocol/derivation.html#batch-submission","protocol/derivation.html#sequencing--batch-submission-overview","protocol/derivation.html#batch-submission-wire-format","protocol/derivation.html#batcher-transaction-format","protocol/derivation.html#frame-format","protocol/derivation.html#channel-format","protocol/derivation.html#batch-format","protocol/derivation.html#architecture","protocol/derivation.html#l2-chain-derivation-pipeline","protocol/derivation.html#l1-traversal","protocol/derivation.html#l1-retrieval","protocol/derivation.html#frame-queue","protocol/derivation.html#channel-bank","protocol/derivation.html#channel-reader-batch-decoding","protocol/derivation.html#batch-queue","protocol/derivation.html#payload-attributes-derivation","protocol/derivation.html#engine-queue","protocol/derivation.html#resetting-the-pipeline","protocol/derivation.html#deriving-payload-attributes","protocol/derivation.html#deriving-the-transaction-list","protocol/derivation.html#network-upgrade-automation-transactions","protocol/derivation.html#building-individual-payload-attributes","protocol/batcher.html#batch-submitter","protocol/batcher.html#overview","fault-proof/index.html#fault-proof","fault-proof/index.html#overview","fault-proof/index.html#pre-image-oracle","fault-proof/index.html#pre-image-key-types","fault-proof/index.html#bootstrapping","fault-proof/index.html#hinting","fault-proof/index.html#pre-image-communication","fault-proof/index.html#fault-proof-program","fault-proof/index.html#prologue","fault-proof/index.html#main-content","fault-proof/index.html#epilogue","fault-proof/index.html#pre-image-hinting-routes","fault-proof/index.html#precompile-accelerators","fault-proof/index.html#fault-proof-vm","fault-proof/index.html#fault-proof-interactive-dispute-game","fault-proof/cannon-fault-proof-vm.html#cannon-fault-proof-virtual-machine","fault-proof/cannon-fault-proof-vm.html#overview","fault-proof/cannon-fault-proof-vm.html#state","fault-proof/cannon-fault-proof-vm.html#state-hash","fault-proof/cannon-fault-proof-vm.html#memory","fault-proof/cannon-fault-proof-vm.html#heap","fault-proof/cannon-fault-proof-vm.html#delay-slots","fault-proof/cannon-fault-proof-vm.html#syscalls","fault-proof/cannon-fault-proof-vm.html#io","fault-proof/cannon-fault-proof-vm.html#standard-streams","fault-proof/cannon-fault-proof-vm.html#hint-communication","fault-proof/cannon-fault-proof-vm.html#pre-image-communication","fault-proof/cannon-fault-proof-vm.html#exceptions","fault-proof/cannon-fault-proof-vm.html#security-model","fault-proof/cannon-fault-proof-vm.html#compiler-correctness","fault-proof/cannon-fault-proof-vm.html#compiler-assumptions","fault-proof/stage-one/index.html#stage-one-decentralization","fault-proof/stage-one/dispute-game-interface.html#dispute-game-interface","fault-proof/stage-one/dispute-game-interface.html#overview","fault-proof/stage-one/dispute-game-interface.html#types","fault-proof/stage-one/dispute-game-interface.html#disputegamefactory-interface","fault-proof/stage-one/dispute-game-interface.html#disputegame-interface","fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game","fault-proof/stage-one/fault-dispute-game.html#overview","fault-proof/stage-one/fault-dispute-game.html#definitions","fault-proof/stage-one/fault-dispute-game.html#virtual-machine-vm","fault-proof/stage-one/fault-dispute-game.html#preimageoracle","fault-proof/stage-one/fault-dispute-game.html#execution-trace","fault-proof/stage-one/fault-dispute-game.html#claims","fault-proof/stage-one/fault-dispute-game.html#anchor-state","fault-proof/stage-one/fault-dispute-game.html#anchor-state-registry","fault-proof/stage-one/fault-dispute-game.html#dag","fault-proof/stage-one/fault-dispute-game.html#subgame","fault-proof/stage-one/fault-dispute-game.html#game-tree","fault-proof/stage-one/fault-dispute-game.html#position","fault-proof/stage-one/fault-dispute-game.html#max_clock_duration","fault-proof/stage-one/fault-dispute-game.html#clock_extension","fault-proof/stage-one/fault-dispute-game.html#freeloader-claims","fault-proof/stage-one/fault-dispute-game.html#core-game-mechanics","fault-proof/stage-one/fault-dispute-game.html#actors","fault-proof/stage-one/fault-dispute-game.html#moves","fault-proof/stage-one/fault-dispute-game.html#l2-block-number-challenge","fault-proof/stage-one/fault-dispute-game.html#step","fault-proof/stage-one/fault-dispute-game.html#step-types","fault-proof/stage-one/fault-dispute-game.html#preimageoracle-interaction","fault-proof/stage-one/fault-dispute-game.html#team-dynamics","fault-proof/stage-one/fault-dispute-game.html#game-clock","fault-proof/stage-one/fault-dispute-game.html#resolution","fault-proof/stage-one/fault-dispute-game.html#finalization","fault-proof/stage-one/honest-challenger-fdg.html#honest-challenger-fault-dispute-game","fault-proof/stage-one/honest-challenger-fdg.html#overview","fault-proof/stage-one/honest-challenger-fdg.html#invariants","fault-proof/stage-one/honest-challenger-fdg.html#fault-dispute-game-responses","fault-proof/stage-one/honest-challenger-fdg.html#moves","fault-proof/stage-one/honest-challenger-fdg.html#steps","fault-proof/stage-one/honest-challenger-fdg.html#timeliness","fault-proof/stage-one/honest-challenger-fdg.html#resolution","fault-proof/stage-one/bond-incentives.html#bond-incentives","fault-proof/stage-one/bond-incentives.html#overview","fault-proof/stage-one/bond-incentives.html#moves","fault-proof/stage-one/bond-incentives.html#subgame-resolution","fault-proof/stage-one/bond-incentives.html#leftmost-claim-incentives","fault-proof/stage-one/bond-incentives.html#fault-proof-mainnet-incentives","fault-proof/stage-one/bond-incentives.html#authenticated-roles","fault-proof/stage-one/bond-incentives.html#base-fee-assumption","fault-proof/stage-one/bond-incentives.html#bond-scaling","fault-proof/stage-one/bond-incentives.html#required-bond-formula","fault-proof/stage-one/bond-incentives.html#other-incentives","fault-proof/stage-one/bond-incentives.html#delayedweth","fault-proof/stage-one/bridge-integration.html#bridge-integration","fault-proof/stage-one/bridge-integration.html#overview","fault-proof/stage-one/bridge-integration.html#legacy-semantics","fault-proof/stage-one/bridge-integration.html#fpac-optimismportal-mods-specification","fault-proof/stage-one/bridge-integration.html#roles---optimismportal","fault-proof/stage-one/bridge-integration.html#new-deployconfig-variables","fault-proof/stage-one/bridge-integration.html#data-structures","fault-proof/stage-one/bridge-integration.html#state-layout","fault-proof/stage-one/bridge-integration.html#provewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#finalizewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#air-gap","fault-proof/stage-one/bridge-integration.html#proxy-upgrade","fault-proof/stage-one/bridge-integration.html#permissioned-faultdisputegame","fault-proof/stage-one/bridge-integration.html#roles---permissioneddisputegame","fault-proof/stage-one/bridge-integration.html#modifications","protocol/precompiles.html#precompiles","protocol/precompiles.html#overview","protocol/precompiles.html#p256verify","protocol/predeploys.html#predeploys","protocol/predeploys.html#overview","protocol/predeploys.html#legacymessagepasser","protocol/predeploys.html#l2tol1messagepasser","protocol/predeploys.html#deployerwhitelist","protocol/predeploys.html#legacyerc20eth","protocol/predeploys.html#weth9","protocol/predeploys.html#l2crossdomainmessenger","protocol/predeploys.html#l2standardbridge","protocol/predeploys.html#l1blocknumber","protocol/predeploys.html#gaspriceoracle","protocol/predeploys.html#l1block","protocol/predeploys.html#proxyadmin","protocol/predeploys.html#sequencerfeevault","protocol/predeploys.html#optimismmintableerc20factory","protocol/predeploys.html#optimismmintableerc721factory","protocol/predeploys.html#basefeevault","protocol/predeploys.html#l1feevault","protocol/predeploys.html#schemaregistry","protocol/predeploys.html#eas","protocol/predeploys.html#beacon-block-root","protocol/preinstalls.html#preinstalls","protocol/preinstalls.html#overview","protocol/preinstalls.html#safe","protocol/preinstalls.html#safel2","protocol/preinstalls.html#multisend","protocol/preinstalls.html#multisendcallonly","protocol/preinstalls.html#safesingletonfactory","protocol/preinstalls.html#multicall3","protocol/preinstalls.html#create2deployer","protocol/preinstalls.html#createx","protocol/preinstalls.html#arachnids-deterministic-deployment-proxy","protocol/preinstalls.html#permit2","protocol/preinstalls.html#erc-4337-v060-entrypoint","protocol/preinstalls.html#erc-4337-v060-sendercreator","protocol/preinstalls.html#erc-4337-v070-entrypoint","protocol/preinstalls.html#erc-4337-v070-sendercreator","protocol/superchain-configuration.html#superchain-configuration","protocol/superchain-configuration.html#overview","protocol/superchain-configuration.html#configurable-values","protocol/superchain-configuration.html#configuration-data-flow","protocol/superchain-configuration.html#pausability","protocol/superchain-upgrades.html#superchain-upgrades","protocol/superchain-upgrades.html#overview","protocol/superchain-upgrades.html#protocol-version","protocol/superchain-upgrades.html#protocol-version-format","protocol/superchain-upgrades.html#protocol-version-exposure","protocol/superchain-upgrades.html#superchain-target","protocol/superchain-upgrades.html#superchain-version-signaling","protocol/superchain-upgrades.html#protocolversions-l1-contract","protocol/superchain-upgrades.html#activation-rules","protocol/superchain-upgrades.html#l2-block-number-based-activation-deprecated","protocol/superchain-upgrades.html#l2-block-timestamp-based-activation","protocol/superchain-upgrades.html#op-stack-protocol-versions","protocol/superchain-upgrades.html#post-bedrock-network-upgrades","protocol/superchain-upgrades.html#activation-timestamps","protocol/system-config.html#system-config","protocol/system-config.html#overview","protocol/system-config.html#system-config-contents-version-0","protocol/system-config.html#batcherhash-bytes32","protocol/system-config.html#scalars","protocol/system-config.html#gaslimit-uint64","protocol/system-config.html#unsafeblocksigner-address","protocol/system-config.html#writing-the-system-config","protocol/system-config.html#reading-the-system-config","protocol/configurability.html#op-stack-configurability","protocol/configurability.html#consensus-parameters","protocol/configurability.html#batch-inbox-address","protocol/configurability.html#batcher-hash","protocol/configurability.html#chain-id","protocol/configurability.html#proof-maturity-delay","protocol/configurability.html#dispute-game-finality","protocol/configurability.html#respected-game-type","protocol/configurability.html#fault-game-max-depth","protocol/configurability.html#fault-game-split-depth","protocol/configurability.html#max-game-clock-duration","protocol/configurability.html#game-clock-extension","protocol/configurability.html#bond-withdrawal-delay","protocol/configurability.html#minimum-large-preimage-proposal-size","protocol/configurability.html#large-preimage-proposal-challenge-period","protocol/configurability.html#fault-game-absolute-prestate","protocol/configurability.html#fault-game-genesis-block","protocol/configurability.html#fault-game-genesis-output-root","protocol/configurability.html#fee-scalar","protocol/configurability.html#gas-limit","protocol/configurability.html#genesis-state","protocol/configurability.html#l2-block-time","protocol/configurability.html#resource-config","protocol/configurability.html#sequencing-window-size","protocol/configurability.html#start-block","protocol/configurability.html#superchain-target","protocol/configurability.html#governance-token","protocol/configurability.html#resource-config-1","protocol/configurability.html#policy-parameters","protocol/configurability.html#data-availability-type","protocol/configurability.html#batch-submission-frequency","protocol/configurability.html#output-frequency","protocol/configurability.html#admin-roles","protocol/configurability.html#l1-proxy-admin","protocol/configurability.html#l1-proxyadmin-owner","protocol/configurability.html#l2-proxy-admin","protocol/configurability.html#l2-proxyadmin-owner","protocol/configurability.html#system-config-owner","protocol/configurability.html#service-roles","protocol/configurability.html#batch-submitter-address","protocol/configurability.html#challenger-address","protocol/configurability.html#guardian-address","protocol/configurability.html#proposer-address","protocol/configurability.html#sequencer-p2p--unsafe-head-signer","protocol/safe-extensions.html#safe-contract-extensions","protocol/safe-extensions.html#guardian-safe","protocol/safe-extensions.html#deputy-guardian-module","protocol/safe-extensions.html#deputy-guardian-module-security-properties","protocol/safe-extensions.html#security-council-liveness-checking-extensions","protocol/safe-extensions.html#the-liveness-guard","protocol/safe-extensions.html#the-liveness-module","protocol/safe-extensions.html#owner-removal-call-flow","protocol/safe-extensions.html#shutdown","protocol/safe-extensions.html#liveness-security-properties","protocol/safe-extensions.html#interdependency-between-the-liveness-guard-and-liveness-module","protocol/safe-extensions.html#operational-considerations","protocol/safe-extensions.html#manual-validation-of-new-owner-liveness","protocol/safe-extensions.html#deploying-the-liveness-checking-system","protocol/safe-extensions.html#modifying-the-liveness-checking-system","protocol/stage-1.html#stage-1-roles-and-requirements","protocol/stage-1.html#overview","protocol/stage-1.html#permissionless-fault-proofs","protocol/stage-1.html#roles-for-stage-1","protocol/stage-1.html#configuration-of-safes","protocol/stage-1.html#ownership-model-diagram","protocol/regolith/overview.html#regolith","protocol/regolith/overview.html#overview","protocol/canyon/overview.html#canyon","protocol/canyon/overview.html#execution-layer","protocol/canyon/overview.html#consensus-layer","protocol/delta/overview.html#delta","protocol/delta/overview.html#consensus-layer","protocol/delta/span-batches.html#span-batches","protocol/delta/span-batches.html#introduction","protocol/delta/span-batches.html#span-batch-format","protocol/delta/span-batches.html#span-batch-size-limits","protocol/delta/span-batches.html#future-batch-format-extension","protocol/delta/span-batches.html#span-batch-activation-rule","protocol/delta/span-batches.html#optimization-strategies","protocol/delta/span-batches.html#truncating-information-and-storing-only-necessary-data","protocol/delta/span-batches.html#tx_data_headers-removal-from-initial-specs","protocol/delta/span-batches.html#chain-id-removal-from-initial-specs","protocol/delta/span-batches.html#reorganization-of-constant-length-transaction-fields","protocol/delta/span-batches.html#rlp-encoding-for-only-variable-length-fields","protocol/delta/span-batches.html#store-y_parity-and-protected_bit-instead-of-v","protocol/delta/span-batches.html#adjust-txs-data-layout-for-better-compression","protocol/delta/span-batches.html#fee_recipients-encoding-scheme","protocol/delta/span-batches.html#how-derivation-works-with-span-batches","protocol/delta/span-batches.html#integration","protocol/delta/span-batches.html#channel-reader-batch-decoding","protocol/delta/span-batches.html#batch-queue","protocol/delta/span-batches.html#batcher","protocol/ecotone/overview.html#ecotone-network-upgrade","protocol/ecotone/overview.html#execution-layer","protocol/ecotone/overview.html#consensus-layer","protocol/ecotone/derivation.html#derivation","protocol/ecotone/derivation.html#ecotone-blob-retrieval","protocol/ecotone/derivation.html#blob-encoding","protocol/ecotone/l1-attributes.html#ecotone-l1-attributes","protocol/ecotone/l1-attributes.html#overview","protocol/ecotone/l1-attributes.html#l1-attributes-predeployed-contract","protocol/ecotone/l1-attributes.html#ecotone-l1block-upgrade","protocol/fjord/overview.html#fjord-network-upgrade","protocol/fjord/overview.html#execution-layer","protocol/fjord/overview.html#consensus-layer","protocol/fjord/exec-engine.html#l2-execution-engine","protocol/fjord/exec-engine.html#fees","protocol/fjord/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/fjord/exec-engine.html#l1-gas-usage-estimation","protocol/fjord/derivation.html#fjord-l2-chain-derivation-changes","protocol/fjord/derivation.html#protocol-parameter-changes","protocol/fjord/derivation.html#timestamp-activation","protocol/fjord/derivation.html#constant-maximum-sequencer-drift","protocol/fjord/derivation.html#rationale","protocol/fjord/derivation.html#security-considerations","protocol/fjord/derivation.html#increasing-max_rlp_bytes_per_channel-and-max_channel_bank_size","protocol/fjord/derivation.html#rationale-1","protocol/fjord/derivation.html#security-considerations-1","protocol/fjord/derivation.html#brotli-channel-compression","protocol/fjord/derivation.html#network-upgrade-automation-transactions","protocol/fjord/derivation.html#gaspriceoracle-deployment","protocol/fjord/derivation.html#gaspriceoracle-proxy-update","protocol/fjord/derivation.html#gaspriceoracle-enable-fjord","protocol/fjord/predeploys.html#predeploys","protocol/fjord/predeploys.html#gaspriceoracle","protocol/fjord/predeploys.html#l1-gas-usage-estimation","protocol/granite/overview.html#granite-network-upgrade","protocol/granite/overview.html#execution-layer","protocol/granite/overview.html#consensus-layer","protocol/granite/exec-engine.html#l2-execution-engine","protocol/granite/exec-engine.html#evm-changes","protocol/granite/exec-engine.html#bn256pairing-precompile-input-restriction","protocol/granite/derivation.html#granite-l2-chain-derivation-changes","protocol/granite/derivation.html#protocol-parameter-changes","protocol/granite/derivation.html#reduce-channel-timeout","protocol/holocene/overview.html#holocene-network-upgrade","protocol/holocene/overview.html#execution-layer","protocol/holocene/overview.html#consensus-layer","protocol/holocene/overview.html#smart-contracts","protocol/holocene/derivation.html#holocene-l2-chain-derivation-changes","protocol/holocene/derivation.html#holocene-derivation","protocol/holocene/derivation.html#summary","protocol/holocene/derivation.html#frame-queue","protocol/holocene/derivation.html#channel-bank","protocol/holocene/derivation.html#pruning","protocol/holocene/derivation.html#timeout","protocol/holocene/derivation.html#reading--frame-loading","protocol/holocene/derivation.html#span-batches","protocol/holocene/derivation.html#batch-queue","protocol/holocene/derivation.html#fast-channel-invalidation","protocol/holocene/derivation.html#engine-queue","protocol/holocene/derivation.html#attributes-builder","protocol/holocene/derivation.html#activation","protocol/holocene/derivation.html#rationale","protocol/holocene/derivation.html#strict-frame-and-batch-ordering","protocol/holocene/derivation.html#partial-span-batch-validity","protocol/holocene/derivation.html#fast-channel-invalidation-1","protocol/holocene/derivation.html#steady-block-derivation","protocol/holocene/derivation.html#less-defensive-protocol","protocol/holocene/derivation.html#security-and-implementation-considerations","protocol/holocene/derivation.html#reorgs","protocol/holocene/derivation.html#batcher-hardening","protocol/holocene/derivation.html#sync-start","protocol/holocene/exec-engine.html#l2-execution-engine","protocol/holocene/exec-engine.html#timestamp-activation","protocol/holocene/exec-engine.html#l2tol1messagepasser-storage-root-in-header","protocol/holocene/exec-engine.html#header-validity-rules","protocol/holocene/exec-engine.html#header-withdrawals-root","protocol/holocene/exec-engine.html#extended-payloadattributesv3","protocol/holocene/exec-engine.html#eip1559params-encoding","protocol/holocene/exec-engine.html#execution","protocol/holocene/exec-engine.html#rationale","protocol/holocene/exec-engine.html#eip1559params-in-header","protocol/holocene/exec-engine.html#header-validity-rules-1","protocol/holocene/exec-engine.html#encoding","protocol/holocene/exec-engine.html#rationale-1","protocol/holocene/predeploys.html#overview","protocol/holocene/predeploys.html#constants","protocol/holocene/predeploys.html#predeploys","protocol/holocene/predeploys.html#l1block","protocol/holocene/predeploys.html#feevault","protocol/holocene/predeploys.html#l2crossdomainmessenger","protocol/holocene/predeploys.html#l2erc721bridge","protocol/holocene/predeploys.html#l2standardbridge","protocol/holocene/predeploys.html#optimismmintableerc721factory","protocol/holocene/predeploys.html#security-considerations","protocol/holocene/predeploys.html#governancetoken","protocol/holocene/configurability.html#configurability","protocol/holocene/configurability.html#overview","protocol/holocene/configurability.html#constants","protocol/holocene/configurability.html#configtype","protocol/holocene/configurability.html#systemconfig","protocol/holocene/configurability.html#configupdate","protocol/holocene/configurability.html#initialization","protocol/holocene/configurability.html#modifying-eip-1559-parameters","protocol/holocene/configurability.html#interface","protocol/holocene/configurability.html#optimismportal","protocol/holocene/configurability.html#interface-1","governance/gov-token.html#governance-token","governance/gov-token.html#overview","governance/gov-token.html#token-minting","governance/gov-token.html#token-burning","governance/gov-token.html#voting-power","governance/gov-token.html#delegation","experimental/custom-gas-token.html#custom-gas-token","experimental/custom-gas-token.html#overview","experimental/custom-gas-token.html#constants","experimental/custom-gas-token.html#properties-of-a-gas-paying-token","experimental/custom-gas-token.html#automated-validation","experimental/custom-gas-token.html#configuring-the-gas-paying-token","experimental/custom-gas-token.html#contract-modifications","experimental/custom-gas-token.html#igastoken-interface","experimental/custom-gas-token.html#gas-token-aware","experimental/custom-gas-token.html#optimismportal","experimental/custom-gas-token.html#standardbridge","experimental/custom-gas-token.html#crossdomainmessenger","experimental/custom-gas-token.html#systemconfig","experimental/custom-gas-token.html#l1block","experimental/custom-gas-token.html#weth9","experimental/custom-gas-token.html#user-flow","experimental/custom-gas-token.html#when-eth-is-the-native-asset","experimental/custom-gas-token.html#when-an-erc20-token-is-the-native-asset","experimental/custom-gas-token.html#differences","experimental/custom-gas-token.html#upgrade","experimental/custom-gas-token.html#l1block-deployment","experimental/custom-gas-token.html#l2crossdomainmessenger-deployment","experimental/custom-gas-token.html#l2standardbridge-deployment","experimental/custom-gas-token.html#l1block-proxy-update","experimental/custom-gas-token.html#l2crossdomainmessenger-proxy-update","experimental/custom-gas-token.html#l2standardbridge-proxy-update","experimental/custom-gas-token.html#selection-of-ether_token_address","experimental/custom-gas-token.html#standard-config","experimental/custom-gas-token.html#fees","experimental/custom-gas-token.html#security-considerations","experimental/custom-gas-token.html#optimismportal-token-allowance","experimental/custom-gas-token.html#interoperability-support","experimental/custom-gas-token.html#wrapped-ether","experimental/alt-da.html#alt-da-mode","experimental/alt-da.html#overview","experimental/alt-da.html#input-commitment-submission","experimental/alt-da.html#da-server","experimental/alt-da.html#data-availability-challenge-contract","experimental/alt-da.html#parameters","experimental/alt-da.html#derivation","experimental/alt-da.html#fault-proof","experimental/alt-da.html#l2-input","experimental/alt-da.html#l1-challenge-status","experimental/alt-da.html#safety-and-finality","experimental/alt-da.html#security-considerations","interop/overview.html#interop","interop/overview.html#specifications","interop/dependency-set.html#the-dependency-set","interop/dependency-set.html#chain-id","interop/dependency-set.html#updating-the-dependency-set","interop/dependency-set.html#security-considerations","interop/dependency-set.html#layer-1-as-part-of-the-dependency-set","interop/messaging.html#messaging","interop/messaging.html#message","interop/messaging.html#message-payload","interop/messaging.html#message-identifier","interop/messaging.html#messaging-ends","interop/messaging.html#initiating-messages","interop/messaging.html#executing-messages","interop/messaging.html#messaging-invariants","interop/messaging.html#timestamp-invariant","interop/messaging.html#chainid-invariant","interop/messaging.html#message-expiry-invariant","interop/messaging.html#message-graph","interop/messaging.html#invalid-messages","interop/messaging.html#intra-block-messaging-cycles","interop/messaging.html#resolving-cross-chain-safety","interop/messaging.html#horizon-timestamp","interop/messaging.html#pruning-the-graph","interop/messaging.html#bounding-the-graph","interop/messaging.html#security-considerations","interop/messaging.html#cyclic-dependencies","interop/messaging.html#transitive-dependencies","interop/predeploys.html#predeploys","interop/predeploys.html#crossl2inbox","interop/predeploys.html#functions","interop/predeploys.html#interop-start-timestamp","interop/predeploys.html#executingmessage-event","interop/predeploys.html#reference-implementation","interop/predeploys.html#deposit-handling","interop/predeploys.html#identifier-getters","interop/predeploys.html#l2tol2crossdomainmessenger","interop/predeploys.html#relaymessage-invariants","interop/predeploys.html#sendexpire-invariants","interop/predeploys.html#relayexpire-invariants","interop/predeploys.html#message-versioning","interop/predeploys.html#no-native-support-for-cross-chain-ether-sends","interop/predeploys.html#interfaces","interop/predeploys.html#optimismsuperchainerc20factory","interop/predeploys.html#optimismsuperchainerc20","interop/predeploys.html#overview","interop/predeploys.html#functions-1","interop/predeploys.html#events","interop/predeploys.html#deployment-flow","interop/predeploys.html#beaconcontract","interop/predeploys.html#overview-1","interop/predeploys.html#l1block","interop/predeploys.html#static-configuration","interop/predeploys.html#dependency-set","interop/predeploys.html#deposit-context","interop/predeploys.html#isdeposit","interop/predeploys.html#optimismmintableerc20factory","interop/predeploys.html#optimismmintableerc20","interop/predeploys.html#updates","interop/predeploys.html#functions-2","interop/predeploys.html#events-1","interop/predeploys.html#l2standardbridge","interop/predeploys.html#updates-1","interop/predeploys.html#invariants","interop/predeploys.html#conversion-flow","interop/predeploys.html#superchainerc20bridge","interop/predeploys.html#overview-2","interop/predeploys.html#functions-3","interop/predeploys.html#events-2","interop/predeploys.html#diagram","interop/predeploys.html#invariants-1","interop/predeploys.html#security-considerations","interop/sequencer.html#sequencer","interop/sequencer.html#sequencer-policy","interop/sequencer.html#block-building","interop/sequencer.html#static-analysis","interop/sequencer.html#dependency-confirmations","interop/sequencer.html#sponsorship","interop/sequencer.html#security-considerations","interop/sequencer.html#cross-chain-message-latency","interop/verifier.html#verifier","interop/verifier.html#derivation-pipeline","interop/verifier.html#depositing-an-executing-message","interop/verifier.html#safety","interop/verifier.html#honest-verifier","interop/verifier.html#security-considerations","interop/verifier.html#forced-inclusion-of-cross-chain-messages","interop/verifier.html#reliance-on-history","interop/rollup-node-p2p.html#p2p-networking","interop/rollup-node-p2p.html#security-considerations","interop/fault-proof.html#fault-proof","interop/fault-proof.html#cascading-dependencies","interop/fault-proof.html#security-considerations","interop/upgrade.html#interop-network-upgrade","interop/upgrade.html#l1-attributes","interop/upgrade.html#l1-attributes-predeployed-contract","interop/upgrade.html#interop-l1block-upgrade","interop/upgrade.html#security-considerations","interop/token-bridging.html#token-bridging","interop/token-bridging.html#overview","interop/token-bridging.html#superchainerc20-standard","interop/token-bridging.html#properties","interop/token-bridging.html#interface","interop/token-bridging.html#superchainerc20bridge","interop/token-bridging.html#diagram","interop/token-bridging.html#implementation","interop/token-bridging.html#future-considerations","interop/token-bridging.html#cross-chain-transferfrom","interop/token-bridging.html#concatenated-action","interop/superchain-weth.html#superchain-weth","interop/superchain-weth.html#motivation-and-constraints","interop/superchain-weth.html#handling-native-assets-other-than-eth","interop/superchain-weth.html#minimizing-protocol-complexity","interop/superchain-weth.html#constants","interop/superchain-weth.html#superchainweth","interop/superchain-weth.html#invariants","interop/superchain-weth.html#ethliquidity","interop/superchain-weth.html#invariants-1","interop/derivation.html#derivation","interop/derivation.html#overview","interop/derivation.html#deposit-context","interop/derivation.html#security-considerations","interop/derivation.html#gas-considerations","interop/tx-pool.html#transaction-pool","interop/tx-pool.html#message-validation","interop/tx-pool.html#system-deposits-transaction-margin","interop/tx-pool.html#security-considerations","interop/tx-pool.html#mempool-denial-of-service","experimental/op-contracts-manager.html#op-contracts-manager","experimental/op-contracts-manager.html#deployment","experimental/op-contracts-manager.html#interface","experimental/op-contracts-manager.html#proxysol","experimental/op-contracts-manager.html#deploy","experimental/op-contracts-manager.html#getter-methods","experimental/op-contracts-manager.html#implementation","experimental/op-contracts-manager.html#batch-inbox-address","experimental/op-contracts-manager.html#contract-deployments","experimental/op-contracts-manager.html#security-considerations","experimental/op-contracts-manager.html#chain-id-source-of-truth","experimental/op-contracts-manager.html#chain-id-frontrunning","experimental/op-contracts-manager.html#chain-id-value","experimental/op-contracts-manager.html#proxy-admin-owner","experimental/op-contracts-manager.html#upgradeability-abi-changes","experimental/gov-token.html#governance-token","experimental/gov-token.html#overview","experimental/gov-token.html#hook-based-integration-with-governancedelegation","experimental/gov-token.html#token-minting","experimental/gov-token.html#token-burning","experimental/gov-token.html#voting-power","experimental/gov-token.html#delegation","glossary.html#glossary","glossary.html#general-terms","glossary.html#layer-1-l1","glossary.html#layer-2-l2","glossary.html#block","glossary.html#eoa","glossary.html#merkle-patricia-trie","glossary.html#chain-re-organization","glossary.html#predeployed-contract-predeploy","glossary.html#preinstalled-contract-preinstall","glossary.html#precompiled-contract-precompile","glossary.html#receipt","glossary.html#transaction-type","glossary.html#fork-choice-rule","glossary.html#priority-gas-auction","glossary.html#sequencing","glossary.html#sequencer","glossary.html#sequencing-window","glossary.html#sequencing-epoch","glossary.html#l1-origin","glossary.html#deposits","glossary.html#deposited-transaction","glossary.html#l1-attributes-deposited-transaction","glossary.html#user-deposited-transaction","glossary.html#depositing-call","glossary.html#depositing-transaction","glossary.html#depositor","glossary.html#deposited-transaction-type","glossary.html#deposit-contract","glossary.html#withdrawals","glossary.html#relayer","glossary.html#finalization-period","glossary.html#batch-submission","glossary.html#data-availability","glossary.html#data-availability-provider","glossary.html#sequencer-batch","glossary.html#channel","glossary.html#channel-frame","glossary.html#batcher","glossary.html#batcher-transaction","glossary.html#batch-submission-frequency","glossary.html#channel-timeout","glossary.html#l2-output-root-proposals","glossary.html#proposer","glossary.html#l2-chain-derivation","glossary.html#l2-derivation-inputs","glossary.html#system-configuration","glossary.html#payload-attributes","glossary.html#l2-genesis-block","glossary.html#l2-chain-inception","glossary.html#safe-l2-block","glossary.html#safe-l2-head","glossary.html#unsafe-l2-block","glossary.html#unsafe-l2-head","glossary.html#unsafe-block-consolidation","glossary.html#finalized-l2-head","glossary.html#other-l2-chain-concepts","glossary.html#address-aliasing","glossary.html#rollup-node","glossary.html#rollup-driver","glossary.html#l1-attributes-predeployed-contract","glossary.html#l2-output-root","glossary.html#l2-output-oracle-contract","glossary.html#validator","glossary.html#fault-proof","glossary.html#time-slot","glossary.html#block-time","glossary.html#unsafe-sync","glossary.html#execution-engine-concepts","glossary.html#execution-engine"],"index":{"documentStore":{"docInfo":{"0":{"body":7,"breadcrumbs":4,"title":3},"1":{"body":51,"breadcrumbs":2,"title":1},"10":{"body":17,"breadcrumbs":3,"title":2},"100":{"body":260,"breadcrumbs":7,"title":1},"101":{"body":81,"breadcrumbs":7,"title":1},"102":{"body":7,"breadcrumbs":7,"title":1},"103":{"body":30,"breadcrumbs":7,"title":1},"104":{"body":9,"breadcrumbs":7,"title":1},"105":{"body":36,"breadcrumbs":7,"title":1},"106":{"body":72,"breadcrumbs":7,"title":1},"107":{"body":99,"breadcrumbs":7,"title":1},"108":{"body":53,"breadcrumbs":7,"title":1},"109":{"body":99,"breadcrumbs":9,"title":3},"11":{"body":33,"breadcrumbs":2,"title":1},"110":{"body":47,"breadcrumbs":9,"title":3},"111":{"body":97,"breadcrumbs":10,"title":4},"112":{"body":80,"breadcrumbs":10,"title":4},"113":{"body":31,"breadcrumbs":8,"title":2},"114":{"body":20,"breadcrumbs":9,"title":3},"115":{"body":26,"breadcrumbs":7,"title":1},"116":{"body":26,"breadcrumbs":7,"title":1},"117":{"body":85,"breadcrumbs":7,"title":1},"118":{"body":13,"breadcrumbs":10,"title":4},"119":{"body":112,"breadcrumbs":7,"title":1},"12":{"body":30,"breadcrumbs":2,"title":1},"120":{"body":57,"breadcrumbs":9,"title":3},"121":{"body":61,"breadcrumbs":9,"title":3},"122":{"body":60,"breadcrumbs":13,"title":4},"123":{"body":143,"breadcrumbs":10,"title":1},"124":{"body":0,"breadcrumbs":11,"title":2},"125":{"body":69,"breadcrumbs":10,"title":1},"126":{"body":149,"breadcrumbs":10,"title":1},"127":{"body":576,"breadcrumbs":10,"title":1},"128":{"body":9,"breadcrumbs":11,"title":2},"129":{"body":5,"breadcrumbs":10,"title":1},"13":{"body":29,"breadcrumbs":2,"title":1},"130":{"body":4,"breadcrumbs":10,"title":1},"131":{"body":4,"breadcrumbs":10,"title":1},"132":{"body":71,"breadcrumbs":11,"title":2},"133":{"body":42,"breadcrumbs":11,"title":2},"134":{"body":233,"breadcrumbs":11,"title":2},"135":{"body":167,"breadcrumbs":11,"title":2},"136":{"body":255,"breadcrumbs":10,"title":1},"137":{"body":130,"breadcrumbs":11,"title":4},"138":{"body":420,"breadcrumbs":8,"title":1},"139":{"body":59,"breadcrumbs":10,"title":3},"14":{"body":84,"breadcrumbs":3,"title":2},"140":{"body":49,"breadcrumbs":9,"title":2},"141":{"body":0,"breadcrumbs":9,"title":2},"142":{"body":147,"breadcrumbs":11,"title":4},"143":{"body":478,"breadcrumbs":11,"title":4},"144":{"body":64,"breadcrumbs":10,"title":3},"145":{"body":115,"breadcrumbs":9,"title":2},"146":{"body":133,"breadcrumbs":9,"title":2},"147":{"body":120,"breadcrumbs":9,"title":2},"148":{"body":33,"breadcrumbs":8,"title":1},"149":{"body":143,"breadcrumbs":11,"title":4},"15":{"body":18,"breadcrumbs":2,"title":1},"150":{"body":47,"breadcrumbs":9,"title":2},"151":{"body":68,"breadcrumbs":9,"title":2},"152":{"body":20,"breadcrumbs":9,"title":2},"153":{"body":311,"breadcrumbs":9,"title":2},"154":{"body":19,"breadcrumbs":11,"title":4},"155":{"body":480,"breadcrumbs":9,"title":2},"156":{"body":57,"breadcrumbs":10,"title":3},"157":{"body":874,"breadcrumbs":9,"title":2},"158":{"body":581,"breadcrumbs":9,"title":2},"159":{"body":43,"breadcrumbs":10,"title":3},"16":{"body":103,"breadcrumbs":2,"title":1},"160":{"body":140,"breadcrumbs":10,"title":3},"161":{"body":700,"breadcrumbs":11,"title":4},"162":{"body":65,"breadcrumbs":11,"title":4},"163":{"body":3,"breadcrumbs":8,"title":2},"164":{"body":116,"breadcrumbs":7,"title":1},"165":{"body":114,"breadcrumbs":7,"title":2},"166":{"body":77,"breadcrumbs":6,"title":1},"167":{"body":52,"breadcrumbs":8,"title":3},"168":{"body":548,"breadcrumbs":9,"title":4},"169":{"body":51,"breadcrumbs":6,"title":1},"17":{"body":62,"breadcrumbs":2,"title":1},"170":{"body":215,"breadcrumbs":6,"title":1},"171":{"body":128,"breadcrumbs":8,"title":3},"172":{"body":55,"breadcrumbs":8,"title":3},"173":{"body":146,"breadcrumbs":6,"title":1},"174":{"body":252,"breadcrumbs":7,"title":2},"175":{"body":142,"breadcrumbs":6,"title":1},"176":{"body":190,"breadcrumbs":9,"title":4},"177":{"body":55,"breadcrumbs":7,"title":2},"178":{"body":104,"breadcrumbs":8,"title":3},"179":{"body":88,"breadcrumbs":10,"title":5},"18":{"body":0,"breadcrumbs":4,"title":3},"180":{"body":30,"breadcrumbs":14,"title":5},"181":{"body":75,"breadcrumbs":10,"title":1},"182":{"body":116,"breadcrumbs":10,"title":1},"183":{"body":51,"breadcrumbs":11,"title":2},"184":{"body":59,"breadcrumbs":10,"title":1},"185":{"body":82,"breadcrumbs":10,"title":1},"186":{"body":63,"breadcrumbs":11,"title":2},"187":{"body":165,"breadcrumbs":10,"title":1},"188":{"body":126,"breadcrumbs":10,"title":1},"189":{"body":26,"breadcrumbs":11,"title":2},"19":{"body":93,"breadcrumbs":4,"title":3},"190":{"body":22,"breadcrumbs":11,"title":2},"191":{"body":162,"breadcrumbs":12,"title":3},"192":{"body":68,"breadcrumbs":10,"title":1},"193":{"body":0,"breadcrumbs":11,"title":2},"194":{"body":147,"breadcrumbs":11,"title":2},"195":{"body":121,"breadcrumbs":11,"title":2},"196":{"body":19,"breadcrumbs":11,"title":3},"197":{"body":8,"breadcrumbs":14,"title":3},"198":{"body":74,"breadcrumbs":12,"title":1},"199":{"body":179,"breadcrumbs":12,"title":1},"2":{"body":28,"breadcrumbs":3,"title":2},"20":{"body":141,"breadcrumbs":2,"title":1},"200":{"body":614,"breadcrumbs":13,"title":2},"201":{"body":348,"breadcrumbs":13,"title":2},"202":{"body":52,"breadcrumbs":14,"title":3},"203":{"body":79,"breadcrumbs":12,"title":1},"204":{"body":0,"breadcrumbs":12,"title":1},"205":{"body":44,"breadcrumbs":14,"title":3},"206":{"body":31,"breadcrumbs":12,"title":1},"207":{"body":25,"breadcrumbs":13,"title":2},"208":{"body":64,"breadcrumbs":12,"title":1},"209":{"body":78,"breadcrumbs":13,"title":2},"21":{"body":19,"breadcrumbs":3,"title":2},"210":{"body":29,"breadcrumbs":14,"title":3},"211":{"body":34,"breadcrumbs":12,"title":1},"212":{"body":80,"breadcrumbs":12,"title":1},"213":{"body":68,"breadcrumbs":13,"title":2},"214":{"body":112,"breadcrumbs":12,"title":1},"215":{"body":12,"breadcrumbs":12,"title":1},"216":{"body":15,"breadcrumbs":12,"title":1},"217":{"body":92,"breadcrumbs":13,"title":2},"218":{"body":22,"breadcrumbs":14,"title":3},"219":{"body":32,"breadcrumbs":12,"title":1},"22":{"body":72,"breadcrumbs":5,"title":2},"220":{"body":216,"breadcrumbs":12,"title":1},"221":{"body":110,"breadcrumbs":15,"title":4},"222":{"body":122,"breadcrumbs":12,"title":1},"223":{"body":123,"breadcrumbs":13,"title":2},"224":{"body":428,"breadcrumbs":13,"title":2},"225":{"body":58,"breadcrumbs":13,"title":2},"226":{"body":128,"breadcrumbs":13,"title":2},"227":{"body":229,"breadcrumbs":12,"title":1},"228":{"body":87,"breadcrumbs":12,"title":1},"229":{"body":12,"breadcrumbs":18,"title":5},"23":{"body":98,"breadcrumbs":6,"title":3},"230":{"body":90,"breadcrumbs":14,"title":1},"231":{"body":39,"breadcrumbs":14,"title":1},"232":{"body":93,"breadcrumbs":17,"title":4},"233":{"body":52,"breadcrumbs":14,"title":1},"234":{"body":65,"breadcrumbs":14,"title":1},"235":{"body":11,"breadcrumbs":14,"title":1},"236":{"body":64,"breadcrumbs":14,"title":1},"237":{"body":31,"breadcrumbs":15,"title":2},"238":{"body":65,"breadcrumbs":14,"title":1},"239":{"body":60,"breadcrumbs":14,"title":1},"24":{"body":0,"breadcrumbs":5,"title":2},"240":{"body":42,"breadcrumbs":15,"title":2},"241":{"body":53,"breadcrumbs":16,"title":3},"242":{"body":15,"breadcrumbs":17,"title":4},"243":{"body":27,"breadcrumbs":15,"title":2},"244":{"body":37,"breadcrumbs":16,"title":3},"245":{"body":90,"breadcrumbs":15,"title":2},"246":{"body":23,"breadcrumbs":16,"title":3},"247":{"body":31,"breadcrumbs":14,"title":1},"248":{"body":367,"breadcrumbs":14,"title":1},"249":{"body":54,"breadcrumbs":12,"title":2},"25":{"body":394,"breadcrumbs":7,"title":4},"250":{"body":27,"breadcrumbs":11,"title":1},"251":{"body":151,"breadcrumbs":12,"title":2},"252":{"body":0,"breadcrumbs":14,"title":4},"253":{"body":10,"breadcrumbs":12,"title":2},"254":{"body":39,"breadcrumbs":13,"title":3},"255":{"body":42,"breadcrumbs":12,"title":2},"256":{"body":96,"breadcrumbs":12,"title":2},"257":{"body":168,"breadcrumbs":12,"title":2},"258":{"body":122,"breadcrumbs":12,"title":2},"259":{"body":168,"breadcrumbs":12,"title":2},"26":{"body":251,"breadcrumbs":7,"title":4},"260":{"body":23,"breadcrumbs":12,"title":2},"261":{"body":43,"breadcrumbs":12,"title":2},"262":{"body":12,"breadcrumbs":12,"title":2},"263":{"body":43,"breadcrumbs":11,"title":1},"264":{"body":4,"breadcrumbs":5,"title":1},"265":{"body":61,"breadcrumbs":5,"title":1},"266":{"body":35,"breadcrumbs":5,"title":1},"267":{"body":24,"breadcrumbs":5,"title":1},"268":{"body":168,"breadcrumbs":5,"title":1},"269":{"body":71,"breadcrumbs":5,"title":1},"27":{"body":70,"breadcrumbs":6,"title":3},"270":{"body":33,"breadcrumbs":5,"title":1},"271":{"body":48,"breadcrumbs":5,"title":1},"272":{"body":41,"breadcrumbs":5,"title":1},"273":{"body":19,"breadcrumbs":5,"title":1},"274":{"body":59,"breadcrumbs":5,"title":1},"275":{"body":84,"breadcrumbs":5,"title":1},"276":{"body":30,"breadcrumbs":5,"title":1},"277":{"body":141,"breadcrumbs":5,"title":1},"278":{"body":16,"breadcrumbs":5,"title":1},"279":{"body":18,"breadcrumbs":5,"title":1},"28":{"body":142,"breadcrumbs":6,"title":3},"280":{"body":29,"breadcrumbs":5,"title":1},"281":{"body":43,"breadcrumbs":5,"title":1},"282":{"body":14,"breadcrumbs":5,"title":1},"283":{"body":25,"breadcrumbs":5,"title":1},"284":{"body":21,"breadcrumbs":5,"title":1},"285":{"body":13,"breadcrumbs":5,"title":1},"286":{"body":10,"breadcrumbs":5,"title":1},"287":{"body":18,"breadcrumbs":7,"title":3},"288":{"body":32,"breadcrumbs":5,"title":1},"289":{"body":96,"breadcrumbs":5,"title":1},"29":{"body":56,"breadcrumbs":5,"title":2},"290":{"body":18,"breadcrumbs":5,"title":1},"291":{"body":16,"breadcrumbs":5,"title":1},"292":{"body":8,"breadcrumbs":5,"title":1},"293":{"body":9,"breadcrumbs":5,"title":1},"294":{"body":51,"breadcrumbs":5,"title":1},"295":{"body":24,"breadcrumbs":5,"title":1},"296":{"body":127,"breadcrumbs":5,"title":1},"297":{"body":26,"breadcrumbs":5,"title":1},"298":{"body":87,"breadcrumbs":8,"title":4},"299":{"body":22,"breadcrumbs":5,"title":1},"3":{"body":17,"breadcrumbs":3,"title":2},"30":{"body":0,"breadcrumbs":6,"title":3},"300":{"body":12,"breadcrumbs":8,"title":4},"301":{"body":14,"breadcrumbs":8,"title":4},"302":{"body":12,"breadcrumbs":8,"title":4},"303":{"body":14,"breadcrumbs":8,"title":4},"304":{"body":13,"breadcrumbs":8,"title":2},"305":{"body":14,"breadcrumbs":7,"title":1},"306":{"body":25,"breadcrumbs":8,"title":2},"307":{"body":29,"breadcrumbs":9,"title":3},"308":{"body":70,"breadcrumbs":7,"title":1},"309":{"body":52,"breadcrumbs":8,"title":2},"31":{"body":69,"breadcrumbs":4,"title":1},"310":{"body":57,"breadcrumbs":7,"title":1},"311":{"body":123,"breadcrumbs":8,"title":2},"312":{"body":326,"breadcrumbs":9,"title":3},"313":{"body":36,"breadcrumbs":9,"title":3},"314":{"body":42,"breadcrumbs":8,"title":2},"315":{"body":88,"breadcrumbs":9,"title":3},"316":{"body":47,"breadcrumbs":9,"title":3},"317":{"body":58,"breadcrumbs":8,"title":2},"318":{"body":72,"breadcrumbs":12,"title":6},"319":{"body":100,"breadcrumbs":11,"title":5},"32":{"body":326,"breadcrumbs":5,"title":2},"320":{"body":130,"breadcrumbs":10,"title":4},"321":{"body":0,"breadcrumbs":10,"title":4},"322":{"body":49,"breadcrumbs":8,"title":2},"323":{"body":31,"breadcrumbs":7,"title":2},"324":{"body":19,"breadcrumbs":6,"title":1},"325":{"body":8,"breadcrumbs":10,"title":5},"326":{"body":43,"breadcrumbs":7,"title":2},"327":{"body":287,"breadcrumbs":6,"title":1},"328":{"body":51,"breadcrumbs":7,"title":2},"329":{"body":51,"breadcrumbs":7,"title":2},"33":{"body":139,"breadcrumbs":5,"title":2},"330":{"body":33,"breadcrumbs":8,"title":3},"331":{"body":219,"breadcrumbs":8,"title":3},"332":{"body":256,"breadcrumbs":7,"title":3},"333":{"body":0,"breadcrumbs":6,"title":2},"334":{"body":26,"breadcrumbs":7,"title":3},"335":{"body":22,"breadcrumbs":6,"title":2},"336":{"body":29,"breadcrumbs":6,"title":2},"337":{"body":41,"breadcrumbs":7,"title":3},"338":{"body":34,"breadcrumbs":7,"title":3},"339":{"body":31,"breadcrumbs":7,"title":3},"34":{"body":6,"breadcrumbs":6,"title":2},"340":{"body":25,"breadcrumbs":8,"title":4},"341":{"body":32,"breadcrumbs":8,"title":4},"342":{"body":26,"breadcrumbs":8,"title":4},"343":{"body":27,"breadcrumbs":7,"title":3},"344":{"body":27,"breadcrumbs":7,"title":3},"345":{"body":36,"breadcrumbs":9,"title":5},"346":{"body":28,"breadcrumbs":9,"title":5},"347":{"body":34,"breadcrumbs":8,"title":4},"348":{"body":30,"breadcrumbs":8,"title":4},"349":{"body":18,"breadcrumbs":9,"title":5},"35":{"body":186,"breadcrumbs":5,"title":1},"350":{"body":20,"breadcrumbs":6,"title":2},"351":{"body":31,"breadcrumbs":6,"title":2},"352":{"body":29,"breadcrumbs":6,"title":2},"353":{"body":24,"breadcrumbs":7,"title":3},"354":{"body":26,"breadcrumbs":6,"title":2},"355":{"body":48,"breadcrumbs":7,"title":3},"356":{"body":19,"breadcrumbs":6,"title":2},"357":{"body":35,"breadcrumbs":6,"title":2},"358":{"body":23,"breadcrumbs":6,"title":2},"359":{"body":18,"breadcrumbs":6,"title":2},"36":{"body":24,"breadcrumbs":6,"title":2},"360":{"body":0,"breadcrumbs":6,"title":2},"361":{"body":34,"breadcrumbs":7,"title":3},"362":{"body":48,"breadcrumbs":7,"title":3},"363":{"body":39,"breadcrumbs":6,"title":2},"364":{"body":0,"breadcrumbs":6,"title":2},"365":{"body":52,"breadcrumbs":7,"title":3},"366":{"body":20,"breadcrumbs":7,"title":3},"367":{"body":31,"breadcrumbs":7,"title":3},"368":{"body":37,"breadcrumbs":7,"title":3},"369":{"body":83,"breadcrumbs":7,"title":3},"37":{"body":8,"breadcrumbs":5,"title":1},"370":{"body":0,"breadcrumbs":6,"title":2},"371":{"body":15,"breadcrumbs":7,"title":3},"372":{"body":33,"breadcrumbs":6,"title":2},"373":{"body":37,"breadcrumbs":6,"title":2},"374":{"body":39,"breadcrumbs":6,"title":2},"375":{"body":28,"breadcrumbs":9,"title":5},"376":{"body":128,"breadcrumbs":8,"title":3},"377":{"body":6,"breadcrumbs":7,"title":2},"378":{"body":178,"breadcrumbs":8,"title":3},"379":{"body":58,"breadcrumbs":10,"title":5},"38":{"body":17,"breadcrumbs":8,"title":3},"380":{"body":52,"breadcrumbs":10,"title":5},"381":{"body":94,"breadcrumbs":7,"title":2},"382":{"body":52,"breadcrumbs":7,"title":2},"383":{"body":51,"breadcrumbs":9,"title":4},"384":{"body":23,"breadcrumbs":6,"title":1},"385":{"body":126,"breadcrumbs":8,"title":3},"386":{"body":29,"breadcrumbs":11,"title":6},"387":{"body":0,"breadcrumbs":7,"title":2},"388":{"body":22,"breadcrumbs":10,"title":5},"389":{"body":62,"breadcrumbs":9,"title":4},"39":{"body":186,"breadcrumbs":6,"title":1},"390":{"body":76,"breadcrumbs":9,"title":4},"391":{"body":14,"breadcrumbs":13,"title":4},"392":{"body":20,"breadcrumbs":10,"title":1},"393":{"body":7,"breadcrumbs":12,"title":3},"394":{"body":82,"breadcrumbs":12,"title":3},"395":{"body":177,"breadcrumbs":11,"title":2},"396":{"body":134,"breadcrumbs":12,"title":3},"397":{"body":3,"breadcrumbs":7,"title":1},"398":{"body":158,"breadcrumbs":7,"title":1},"399":{"body":40,"breadcrumbs":7,"title":1},"4":{"body":29,"breadcrumbs":2,"title":1},"40":{"body":75,"breadcrumbs":7,"title":2},"400":{"body":51,"breadcrumbs":8,"title":2},"401":{"body":3,"breadcrumbs":8,"title":2},"402":{"body":16,"breadcrumbs":7,"title":1},"403":{"body":9,"breadcrumbs":8,"title":2},"404":{"body":70,"breadcrumbs":10,"title":2},"405":{"body":150,"breadcrumbs":9,"title":1},"406":{"body":314,"breadcrumbs":11,"title":3},"407":{"body":38,"breadcrumbs":12,"title":4},"408":{"body":74,"breadcrumbs":12,"title":4},"409":{"body":41,"breadcrumbs":12,"title":4},"41":{"body":13,"breadcrumbs":6,"title":1},"410":{"body":0,"breadcrumbs":10,"title":2},"411":{"body":27,"breadcrumbs":13,"title":5},"412":{"body":19,"breadcrumbs":12,"title":4},"413":{"body":20,"breadcrumbs":13,"title":5},"414":{"body":24,"breadcrumbs":13,"title":5},"415":{"body":44,"breadcrumbs":13,"title":5},"416":{"body":64,"breadcrumbs":13,"title":5},"417":{"body":32,"breadcrumbs":14,"title":6},"418":{"body":75,"breadcrumbs":11,"title":3},"419":{"body":142,"breadcrumbs":12,"title":4},"42":{"body":36,"breadcrumbs":7,"title":2},"420":{"body":0,"breadcrumbs":9,"title":1},"421":{"body":18,"breadcrumbs":12,"title":4},"422":{"body":482,"breadcrumbs":10,"title":2},"423":{"body":101,"breadcrumbs":9,"title":1},"424":{"body":18,"breadcrumbs":9,"title":3},"425":{"body":80,"breadcrumbs":8,"title":2},"426":{"body":30,"breadcrumbs":8,"title":2},"427":{"body":7,"breadcrumbs":8,"title":1},"428":{"body":110,"breadcrumbs":10,"title":3},"429":{"body":279,"breadcrumbs":9,"title":2},"43":{"body":6,"breadcrumbs":8,"title":3},"430":{"body":10,"breadcrumbs":11,"title":3},"431":{"body":203,"breadcrumbs":9,"title":1},"432":{"body":116,"breadcrumbs":12,"title":4},"433":{"body":111,"breadcrumbs":11,"title":3},"434":{"body":6,"breadcrumbs":9,"title":3},"435":{"body":22,"breadcrumbs":8,"title":2},"436":{"body":16,"breadcrumbs":8,"title":2},"437":{"body":27,"breadcrumbs":11,"title":3},"438":{"body":0,"breadcrumbs":9,"title":1},"439":{"body":266,"breadcrumbs":14,"title":6},"44":{"body":8,"breadcrumbs":8,"title":3},"440":{"body":24,"breadcrumbs":12,"title":4},"441":{"body":35,"breadcrumbs":12,"title":5},"442":{"body":35,"breadcrumbs":10,"title":3},"443":{"body":51,"breadcrumbs":9,"title":2},"444":{"body":34,"breadcrumbs":11,"title":4},"445":{"body":53,"breadcrumbs":8,"title":1},"446":{"body":66,"breadcrumbs":9,"title":2},"447":{"body":57,"breadcrumbs":10,"title":3},"448":{"body":110,"breadcrumbs":8,"title":1},"449":{"body":115,"breadcrumbs":9,"title":2},"45":{"body":45,"breadcrumbs":8,"title":3},"450":{"body":75,"breadcrumbs":10,"title":3},"451":{"body":43,"breadcrumbs":11,"title":4},"452":{"body":106,"breadcrumbs":9,"title":2},"453":{"body":75,"breadcrumbs":10,"title":3},"454":{"body":66,"breadcrumbs":10,"title":3},"455":{"body":7,"breadcrumbs":8,"title":1},"456":{"body":130,"breadcrumbs":8,"title":1},"457":{"body":91,"breadcrumbs":11,"title":4},"458":{"body":6,"breadcrumbs":9,"title":3},"459":{"body":5,"breadcrumbs":8,"title":2},"46":{"body":64,"breadcrumbs":6,"title":1},"460":{"body":4,"breadcrumbs":8,"title":2},"461":{"body":8,"breadcrumbs":11,"title":3},"462":{"body":0,"breadcrumbs":10,"title":2},"463":{"body":25,"breadcrumbs":12,"title":4},"464":{"body":8,"breadcrumbs":12,"title":5},"465":{"body":20,"breadcrumbs":10,"title":3},"466":{"body":18,"breadcrumbs":10,"title":3},"467":{"body":12,"breadcrumbs":9,"title":3},"468":{"body":4,"breadcrumbs":8,"title":2},"469":{"body":2,"breadcrumbs":8,"title":2},"47":{"body":40,"breadcrumbs":6,"title":1},"470":{"body":2,"breadcrumbs":8,"title":2},"471":{"body":52,"breadcrumbs":12,"title":5},"472":{"body":0,"breadcrumbs":9,"title":2},"473":{"body":114,"breadcrumbs":8,"title":1},"474":{"body":174,"breadcrumbs":9,"title":2},"475":{"body":13,"breadcrumbs":9,"title":2},"476":{"body":32,"breadcrumbs":8,"title":1},"477":{"body":6,"breadcrumbs":8,"title":1},"478":{"body":77,"breadcrumbs":10,"title":3},"479":{"body":167,"breadcrumbs":9,"title":2},"48":{"body":205,"breadcrumbs":8,"title":3},"480":{"body":83,"breadcrumbs":9,"title":2},"481":{"body":39,"breadcrumbs":10,"title":3},"482":{"body":40,"breadcrumbs":9,"title":2},"483":{"body":72,"breadcrumbs":9,"title":2},"484":{"body":102,"breadcrumbs":8,"title":1},"485":{"body":0,"breadcrumbs":8,"title":1},"486":{"body":65,"breadcrumbs":11,"title":4},"487":{"body":59,"breadcrumbs":11,"title":4},"488":{"body":38,"breadcrumbs":10,"title":3},"489":{"body":54,"breadcrumbs":10,"title":3},"49":{"body":114,"breadcrumbs":8,"title":3},"490":{"body":70,"breadcrumbs":10,"title":3},"491":{"body":0,"breadcrumbs":10,"title":3},"492":{"body":85,"breadcrumbs":8,"title":1},"493":{"body":186,"breadcrumbs":9,"title":2},"494":{"body":180,"breadcrumbs":9,"title":2},"495":{"body":34,"breadcrumbs":11,"title":3},"496":{"body":15,"breadcrumbs":10,"title":2},"497":{"body":30,"breadcrumbs":12,"title":4},"498":{"body":40,"breadcrumbs":11,"title":3},"499":{"body":155,"breadcrumbs":11,"title":3},"5":{"body":40,"breadcrumbs":2,"title":1},"50":{"body":57,"breadcrumbs":8,"title":3},"500":{"body":33,"breadcrumbs":10,"title":2},"501":{"body":16,"breadcrumbs":10,"title":2},"502":{"body":45,"breadcrumbs":9,"title":1},"503":{"body":31,"breadcrumbs":9,"title":1},"504":{"body":13,"breadcrumbs":10,"title":2},"505":{"body":23,"breadcrumbs":11,"title":3},"506":{"body":6,"breadcrumbs":9,"title":1},"507":{"body":53,"breadcrumbs":9,"title":1},"508":{"body":53,"breadcrumbs":8,"title":1},"509":{"body":89,"breadcrumbs":8,"title":1},"51":{"body":24,"breadcrumbs":9,"title":4},"510":{"body":65,"breadcrumbs":8,"title":1},"511":{"body":149,"breadcrumbs":8,"title":1},"512":{"body":37,"breadcrumbs":8,"title":1},"513":{"body":11,"breadcrumbs":8,"title":1},"514":{"body":11,"breadcrumbs":8,"title":1},"515":{"body":11,"breadcrumbs":8,"title":1},"516":{"body":11,"breadcrumbs":8,"title":1},"517":{"body":0,"breadcrumbs":9,"title":2},"518":{"body":9,"breadcrumbs":8,"title":1},"519":{"body":28,"breadcrumbs":8,"title":1},"52":{"body":370,"breadcrumbs":6,"title":1},"520":{"body":7,"breadcrumbs":8,"title":1},"521":{"body":0,"breadcrumbs":8,"title":1},"522":{"body":58,"breadcrumbs":8,"title":1},"523":{"body":0,"breadcrumbs":8,"title":1},"524":{"body":56,"breadcrumbs":8,"title":1},"525":{"body":28,"breadcrumbs":8,"title":1},"526":{"body":15,"breadcrumbs":11,"title":4},"527":{"body":84,"breadcrumbs":8,"title":1},"528":{"body":7,"breadcrumbs":8,"title":1},"529":{"body":53,"breadcrumbs":8,"title":1},"53":{"body":146,"breadcrumbs":7,"title":2},"530":{"body":15,"breadcrumbs":5,"title":2},"531":{"body":49,"breadcrumbs":4,"title":1},"532":{"body":26,"breadcrumbs":5,"title":2},"533":{"body":25,"breadcrumbs":5,"title":2},"534":{"body":94,"breadcrumbs":5,"title":2},"535":{"body":37,"breadcrumbs":4,"title":1},"536":{"body":73,"breadcrumbs":7,"title":3},"537":{"body":83,"breadcrumbs":5,"title":1},"538":{"body":50,"breadcrumbs":5,"title":1},"539":{"body":77,"breadcrumbs":8,"title":4},"54":{"body":70,"breadcrumbs":9,"title":4},"540":{"body":50,"breadcrumbs":6,"title":2},"541":{"body":146,"breadcrumbs":8,"title":4},"542":{"body":0,"breadcrumbs":6,"title":2},"543":{"body":80,"breadcrumbs":6,"title":2},"544":{"body":20,"breadcrumbs":7,"title":3},"545":{"body":188,"breadcrumbs":5,"title":1},"546":{"body":65,"breadcrumbs":5,"title":1},"547":{"body":90,"breadcrumbs":5,"title":1},"548":{"body":85,"breadcrumbs":5,"title":1},"549":{"body":54,"breadcrumbs":5,"title":1},"55":{"body":25,"breadcrumbs":10,"title":5},"550":{"body":23,"breadcrumbs":5,"title":1},"551":{"body":39,"breadcrumbs":6,"title":2},"552":{"body":72,"breadcrumbs":7,"title":3},"553":{"body":86,"breadcrumbs":8,"title":4},"554":{"body":26,"breadcrumbs":5,"title":1},"555":{"body":146,"breadcrumbs":5,"title":1},"556":{"body":12,"breadcrumbs":6,"title":2},"557":{"body":12,"breadcrumbs":6,"title":2},"558":{"body":12,"breadcrumbs":6,"title":2},"559":{"body":12,"breadcrumbs":7,"title":3},"56":{"body":17,"breadcrumbs":8,"title":3},"560":{"body":12,"breadcrumbs":7,"title":3},"561":{"body":12,"breadcrumbs":7,"title":3},"562":{"body":17,"breadcrumbs":6,"title":2},"563":{"body":16,"breadcrumbs":6,"title":2},"564":{"body":47,"breadcrumbs":5,"title":1},"565":{"body":0,"breadcrumbs":6,"title":2},"566":{"body":25,"breadcrumbs":7,"title":3},"567":{"body":37,"breadcrumbs":6,"title":2},"568":{"body":17,"breadcrumbs":6,"title":2},"569":{"body":48,"breadcrumbs":6,"title":3},"57":{"body":19,"breadcrumbs":9,"title":4},"570":{"body":73,"breadcrumbs":4,"title":1},"571":{"body":194,"breadcrumbs":6,"title":3},"572":{"body":113,"breadcrumbs":5,"title":2},"573":{"body":0,"breadcrumbs":7,"title":4},"574":{"body":356,"breadcrumbs":4,"title":1},"575":{"body":393,"breadcrumbs":4,"title":1},"576":{"body":21,"breadcrumbs":5,"title":2},"577":{"body":7,"breadcrumbs":6,"title":3},"578":{"body":9,"breadcrumbs":8,"title":5},"579":{"body":125,"breadcrumbs":5,"title":2},"58":{"body":134,"breadcrumbs":9,"title":4},"580":{"body":63,"breadcrumbs":5,"title":2},"581":{"body":165,"breadcrumbs":3,"title":1},"582":{"body":78,"breadcrumbs":3,"title":1},"583":{"body":142,"breadcrumbs":6,"title":2},"584":{"body":69,"breadcrumbs":6,"title":2},"585":{"body":45,"breadcrumbs":7,"title":3},"586":{"body":0,"breadcrumbs":6,"title":2},"587":{"body":46,"breadcrumbs":9,"title":5},"588":{"body":50,"breadcrumbs":4,"title":1},"589":{"body":6,"breadcrumbs":4,"title":1},"59":{"body":92,"breadcrumbs":8,"title":3},"590":{"body":37,"breadcrumbs":5,"title":2},"591":{"body":121,"breadcrumbs":5,"title":2},"592":{"body":0,"breadcrumbs":5,"title":2},"593":{"body":43,"breadcrumbs":5,"title":2},"594":{"body":77,"breadcrumbs":5,"title":2},"595":{"body":41,"breadcrumbs":5,"title":2},"596":{"body":30,"breadcrumbs":5,"title":2},"597":{"body":21,"breadcrumbs":5,"title":2},"598":{"body":59,"breadcrumbs":6,"title":3},"599":{"body":25,"breadcrumbs":5,"title":2},"6":{"body":0,"breadcrumbs":2,"title":1},"60":{"body":121,"breadcrumbs":7,"title":2},"600":{"body":84,"breadcrumbs":5,"title":2},"601":{"body":28,"breadcrumbs":7,"title":4},"602":{"body":64,"breadcrumbs":7,"title":4},"603":{"body":15,"breadcrumbs":5,"title":2},"604":{"body":62,"breadcrumbs":5,"title":2},"605":{"body":67,"breadcrumbs":5,"title":2},"606":{"body":0,"breadcrumbs":5,"title":2},"607":{"body":27,"breadcrumbs":5,"title":2},"608":{"body":20,"breadcrumbs":5,"title":2},"609":{"body":118,"breadcrumbs":4,"title":1},"61":{"body":35,"breadcrumbs":6,"title":1},"610":{"body":25,"breadcrumbs":4,"title":1},"611":{"body":141,"breadcrumbs":4,"title":1},"612":{"body":67,"breadcrumbs":6,"title":3},"613":{"body":50,"breadcrumbs":5,"title":2},"614":{"body":175,"breadcrumbs":5,"title":2},"615":{"body":31,"breadcrumbs":5,"title":2},"616":{"body":11,"breadcrumbs":5,"title":2},"617":{"body":45,"breadcrumbs":4,"title":1},"618":{"body":9,"breadcrumbs":5,"title":2},"619":{"body":21,"breadcrumbs":5,"title":2},"62":{"body":132,"breadcrumbs":6,"title":1},"620":{"body":20,"breadcrumbs":5,"title":2},"621":{"body":17,"breadcrumbs":5,"title":2},"622":{"body":26,"breadcrumbs":9,"title":6},"623":{"body":464,"breadcrumbs":4,"title":1},"624":{"body":4,"breadcrumbs":4,"title":1},"625":{"body":31,"breadcrumbs":4,"title":1},"626":{"body":71,"breadcrumbs":4,"title":1},"627":{"body":85,"breadcrumbs":4,"title":1},"628":{"body":25,"breadcrumbs":4,"title":1},"629":{"body":49,"breadcrumbs":5,"title":2},"63":{"body":8,"breadcrumbs":7,"title":2},"630":{"body":4,"breadcrumbs":4,"title":1},"631":{"body":25,"breadcrumbs":4,"title":1},"632":{"body":6,"breadcrumbs":4,"title":1},"633":{"body":108,"breadcrumbs":5,"title":2},"634":{"body":113,"breadcrumbs":5,"title":2},"635":{"body":17,"breadcrumbs":5,"title":2},"636":{"body":34,"breadcrumbs":4,"title":1},"637":{"body":4,"breadcrumbs":4,"title":1},"638":{"body":34,"breadcrumbs":4,"title":1},"639":{"body":19,"breadcrumbs":4,"title":1},"64":{"body":17,"breadcrumbs":6,"title":1},"640":{"body":128,"breadcrumbs":4,"title":1},"641":{"body":34,"breadcrumbs":4,"title":1},"642":{"body":4,"breadcrumbs":4,"title":1},"643":{"body":110,"breadcrumbs":4,"title":1},"644":{"body":57,"breadcrumbs":4,"title":1},"645":{"body":53,"breadcrumbs":5,"title":2},"646":{"body":4,"breadcrumbs":4,"title":1},"647":{"body":19,"breadcrumbs":4,"title":1},"648":{"body":111,"breadcrumbs":4,"title":1},"649":{"body":40,"breadcrumbs":4,"title":1},"65":{"body":133,"breadcrumbs":6,"title":1},"650":{"body":83,"breadcrumbs":4,"title":1},"651":{"body":209,"breadcrumbs":4,"title":1},"652":{"body":1,"breadcrumbs":5,"title":2},"653":{"body":29,"breadcrumbs":4,"title":1},"654":{"body":39,"breadcrumbs":5,"title":2},"655":{"body":28,"breadcrumbs":5,"title":2},"656":{"body":21,"breadcrumbs":5,"title":2},"657":{"body":336,"breadcrumbs":5,"title":2},"658":{"body":25,"breadcrumbs":4,"title":1},"659":{"body":0,"breadcrumbs":5,"title":2},"66":{"body":81,"breadcrumbs":7,"title":2},"660":{"body":33,"breadcrumbs":7,"title":4},"661":{"body":31,"breadcrumbs":4,"title":1},"662":{"body":106,"breadcrumbs":5,"title":2},"663":{"body":78,"breadcrumbs":6,"title":3},"664":{"body":326,"breadcrumbs":4,"title":1},"665":{"body":26,"breadcrumbs":5,"title":2},"666":{"body":0,"breadcrumbs":5,"title":2},"667":{"body":113,"breadcrumbs":8,"title":5},"668":{"body":38,"breadcrumbs":5,"title":2},"669":{"body":58,"breadcrumbs":7,"title":2},"67":{"body":60,"breadcrumbs":8,"title":3},"670":{"body":1,"breadcrumbs":7,"title":2},"671":{"body":21,"breadcrumbs":6,"title":2},"672":{"body":36,"breadcrumbs":6,"title":2},"673":{"body":1,"breadcrumbs":6,"title":2},"674":{"body":102,"breadcrumbs":6,"title":3},"675":{"body":27,"breadcrumbs":5,"title":2},"676":{"body":36,"breadcrumbs":7,"title":4},"677":{"body":71,"breadcrumbs":6,"title":3},"678":{"body":1,"breadcrumbs":5,"title":2},"679":{"body":21,"breadcrumbs":6,"title":2},"68":{"body":54,"breadcrumbs":8,"title":3},"680":{"body":29,"breadcrumbs":5,"title":1},"681":{"body":0,"breadcrumbs":6,"title":2},"682":{"body":98,"breadcrumbs":5,"title":1},"683":{"body":54,"breadcrumbs":5,"title":1},"684":{"body":54,"breadcrumbs":5,"title":1},"685":{"body":83,"breadcrumbs":5,"title":1},"686":{"body":60,"breadcrumbs":5,"title":1},"687":{"body":0,"breadcrumbs":6,"title":2},"688":{"body":94,"breadcrumbs":7,"title":3},"689":{"body":156,"breadcrumbs":6,"title":2},"69":{"body":97,"breadcrumbs":8,"title":3},"690":{"body":58,"breadcrumbs":5,"title":2},"691":{"body":40,"breadcrumbs":5,"title":2},"692":{"body":53,"breadcrumbs":7,"title":4},"693":{"body":33,"breadcrumbs":6,"title":3},"694":{"body":8,"breadcrumbs":4,"title":1},"695":{"body":0,"breadcrumbs":4,"title":1},"696":{"body":105,"breadcrumbs":4,"title":1},"697":{"body":0,"breadcrumbs":4,"title":1},"698":{"body":136,"breadcrumbs":4,"title":1},"699":{"body":19,"breadcrumbs":4,"title":1},"7":{"body":47,"breadcrumbs":3,"title":2},"70":{"body":0,"breadcrumbs":7,"title":2},"700":{"body":0,"breadcrumbs":4,"title":1},"701":{"body":271,"breadcrumbs":5,"title":2},"702":{"body":0,"breadcrumbs":5,"title":2},"703":{"body":28,"breadcrumbs":5,"title":2},"704":{"body":76,"breadcrumbs":6,"title":2},"705":{"body":105,"breadcrumbs":6,"title":2},"706":{"body":70,"breadcrumbs":8,"title":4},"707":{"body":0,"breadcrumbs":6,"title":2},"708":{"body":43,"breadcrumbs":7,"title":3},"709":{"body":79,"breadcrumbs":7,"title":3},"71":{"body":79,"breadcrumbs":9,"title":4},"710":{"body":10,"breadcrumbs":5,"title":1},"711":{"body":10,"breadcrumbs":5,"title":1},"712":{"body":35,"breadcrumbs":5,"title":1},"713":{"body":106,"breadcrumbs":5,"title":1},"714":{"body":92,"breadcrumbs":6,"title":2},"715":{"body":0,"breadcrumbs":5,"title":1},"716":{"body":22,"breadcrumbs":7,"title":3},"717":{"body":98,"breadcrumbs":6,"title":2},"718":{"body":0,"breadcrumbs":6,"title":2},"719":{"body":92,"breadcrumbs":8,"title":4},"72":{"body":25,"breadcrumbs":11,"title":6},"720":{"body":30,"breadcrumbs":7,"title":3},"721":{"body":50,"breadcrumbs":7,"title":3},"722":{"body":22,"breadcrumbs":7,"title":3},"723":{"body":31,"breadcrumbs":7,"title":3},"724":{"body":15,"breadcrumbs":5,"title":2},"725":{"body":43,"breadcrumbs":4,"title":1},"726":{"body":147,"breadcrumbs":7,"title":4},"727":{"body":58,"breadcrumbs":5,"title":2},"728":{"body":27,"breadcrumbs":5,"title":2},"729":{"body":67,"breadcrumbs":5,"title":2},"73":{"body":63,"breadcrumbs":10,"title":5},"730":{"body":49,"breadcrumbs":4,"title":1},"731":{"body":161,"breadcrumbs":2,"title":1},"732":{"body":0,"breadcrumbs":3,"title":2},"733":{"body":9,"breadcrumbs":4,"title":3},"734":{"body":12,"breadcrumbs":4,"title":3},"735":{"body":62,"breadcrumbs":2,"title":1},"736":{"body":12,"breadcrumbs":2,"title":1},"737":{"body":34,"breadcrumbs":4,"title":3},"738":{"body":38,"breadcrumbs":4,"title":3},"739":{"body":13,"breadcrumbs":4,"title":3},"74":{"body":17,"breadcrumbs":11,"title":4},"740":{"body":27,"breadcrumbs":4,"title":3},"741":{"body":27,"breadcrumbs":4,"title":3},"742":{"body":45,"breadcrumbs":2,"title":1},"743":{"body":19,"breadcrumbs":3,"title":2},"744":{"body":34,"breadcrumbs":4,"title":3},"745":{"body":57,"breadcrumbs":4,"title":3},"746":{"body":33,"breadcrumbs":2,"title":1},"747":{"body":31,"breadcrumbs":2,"title":1},"748":{"body":50,"breadcrumbs":3,"title":2},"749":{"body":36,"breadcrumbs":3,"title":2},"75":{"body":122,"breadcrumbs":8,"title":1},"750":{"body":9,"breadcrumbs":3,"title":2},"751":{"body":80,"breadcrumbs":2,"title":1},"752":{"body":34,"breadcrumbs":3,"title":2},"753":{"body":41,"breadcrumbs":5,"title":4},"754":{"body":21,"breadcrumbs":4,"title":3},"755":{"body":20,"breadcrumbs":3,"title":2},"756":{"body":9,"breadcrumbs":3,"title":2},"757":{"body":15,"breadcrumbs":2,"title":1},"758":{"body":21,"breadcrumbs":4,"title":3},"759":{"body":46,"breadcrumbs":3,"title":2},"76":{"body":41,"breadcrumbs":9,"title":2},"760":{"body":53,"breadcrumbs":2,"title":1},"761":{"body":10,"breadcrumbs":2,"title":1},"762":{"body":30,"breadcrumbs":3,"title":2},"763":{"body":0,"breadcrumbs":3,"title":2},"764":{"body":48,"breadcrumbs":3,"title":2},"765":{"body":36,"breadcrumbs":4,"title":3},"766":{"body":54,"breadcrumbs":3,"title":2},"767":{"body":77,"breadcrumbs":2,"title":1},"768":{"body":22,"breadcrumbs":3,"title":2},"769":{"body":40,"breadcrumbs":2,"title":1},"77":{"body":18,"breadcrumbs":9,"title":2},"770":{"body":50,"breadcrumbs":3,"title":2},"771":{"body":105,"breadcrumbs":4,"title":3},"772":{"body":97,"breadcrumbs":3,"title":2},"773":{"body":0,"breadcrumbs":5,"title":4},"774":{"body":36,"breadcrumbs":2,"title":1},"775":{"body":20,"breadcrumbs":4,"title":3},"776":{"body":38,"breadcrumbs":4,"title":3},"777":{"body":29,"breadcrumbs":3,"title":2},"778":{"body":45,"breadcrumbs":3,"title":2},"779":{"body":121,"breadcrumbs":4,"title":3},"78":{"body":294,"breadcrumbs":10,"title":3},"780":{"body":21,"breadcrumbs":4,"title":3},"781":{"body":18,"breadcrumbs":4,"title":3},"782":{"body":10,"breadcrumbs":4,"title":3},"783":{"body":25,"breadcrumbs":4,"title":3},"784":{"body":10,"breadcrumbs":4,"title":3},"785":{"body":49,"breadcrumbs":4,"title":3},"786":{"body":21,"breadcrumbs":4,"title":3},"787":{"body":0,"breadcrumbs":4,"title":3},"788":{"body":17,"breadcrumbs":3,"title":2},"789":{"body":91,"breadcrumbs":3,"title":2},"79":{"body":79,"breadcrumbs":11,"title":4},"790":{"body":26,"breadcrumbs":3,"title":2},"791":{"body":22,"breadcrumbs":5,"title":4},"792":{"body":14,"breadcrumbs":4,"title":3},"793":{"body":7,"breadcrumbs":5,"title":4},"794":{"body":46,"breadcrumbs":2,"title":1},"795":{"body":14,"breadcrumbs":3,"title":2},"796":{"body":32,"breadcrumbs":3,"title":2},"797":{"body":36,"breadcrumbs":3,"title":2},"798":{"body":21,"breadcrumbs":3,"title":2},"799":{"body":0,"breadcrumbs":4,"title":3},"8":{"body":51,"breadcrumbs":3,"title":2},"80":{"body":79,"breadcrumbs":10,"title":3},"800":{"body":71,"breadcrumbs":3,"title":2},"81":{"body":23,"breadcrumbs":10,"title":5},"82":{"body":74,"breadcrumbs":6,"title":1},"83":{"body":36,"breadcrumbs":9,"title":4},"84":{"body":112,"breadcrumbs":7,"title":2},"85":{"body":128,"breadcrumbs":9,"title":4},"86":{"body":153,"breadcrumbs":10,"title":5},"87":{"body":17,"breadcrumbs":6,"title":1},"88":{"body":0,"breadcrumbs":7,"title":2},"89":{"body":36,"breadcrumbs":7,"title":2},"9":{"body":27,"breadcrumbs":3,"title":2},"90":{"body":81,"breadcrumbs":9,"title":3},"91":{"body":29,"breadcrumbs":8,"title":2},"92":{"body":34,"breadcrumbs":9,"title":3},"93":{"body":54,"breadcrumbs":9,"title":3},"94":{"body":16,"breadcrumbs":7,"title":1},"95":{"body":56,"breadcrumbs":8,"title":2},"96":{"body":22,"breadcrumbs":11,"title":5},"97":{"body":19,"breadcrumbs":11,"title":5},"98":{"body":419,"breadcrumbs":12,"title":6},"99":{"body":0,"breadcrumbs":8,"title":2}},"docs":{"0":{"body":"Table of Contents About Optimism About the OP Stack Site Navigation","breadcrumbs":"Introduction » OP Stack Specification","id":"0","title":"OP Stack Specification"},"1":{"body":"Optimism is a project dedicated to scaling Ethereum's technology and expanding its ability to coordinate people from across the world to build effective decentralized economies and governance systems. The Optimism Collective builds open-source software that powers scalable blockchains and aims to address key governance and economic challenges in the wider Ethereum ecosystem. Optimism operates on the principle of impact=profit , the idea that individuals who positively impact the Collective should be proportionally rewarded with profit. Change the incentives and you change the world.","breadcrumbs":"Introduction » About Optimism","id":"1","title":"About Optimism"},"10":{"body":"We strive to preserve three critical properties: liveness, validity, and availability. A protocol that can maintain these properties can, effectively, scale Ethereum without sacrificing security.","breadcrumbs":"Background » Protocol Guarantees","id":"10","title":"Protocol Guarantees"},"100":{"body":"This updates which L2 blocks the engine considers to be canonical (forkchoiceState argument), and optionally initiates block production (payloadAttributes argument). Within the rollup, the types of forkchoice updates translate as: headBlockHash: block hash of the head of the canonical chain. Labeled \"unsafe\" in user JSON-RPC. Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts. safeBlockHash: block hash of the canonical chain, derived from L1 data, unlikely to reorg. finalizedBlockHash: irreversible block hash, matches lower boundary of the dispute period. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV2 : the extended PayloadAttributesV2 Extended PayloadAttributesV2 PayloadAttributesV2 is extended to: PayloadAttributesV2: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The type notation used here refers to the HEX value encoding used by the Ethereum JSON-RPC API specification , as this structure will need to be sent over JSON-RPC. array refers to a JSON array. Each item of the transactions array is a byte list encoding a transaction: TransactionType || TransactionPayload or LegacyTransaction, as defined in EIP-2718 . This is equivalent to the transactions field in ExecutionPayloadV2 The transactions field is optional: If empty or missing: no changes to engine behavior. The sequencers will (if enabled) build a block by consuming transactions from the transaction pool. If present and non-empty: the payload MUST be produced starting with this exact list of transactions. The rollup driver determines the transaction list based on deterministic L1 inputs. The noTxPool is optional as well, and extends the transactions meaning: If false, the execution engine is free to pack additional transactions from external sources like the tx pool into the payload, after any of the transactions. This is the default behavior a L1 node implements. If true, the execution engine must not change anything about the given list of transactions. If the transactions field is present, the engine must execute the transactions in order and return STATUS_INVALID if there is an error processing the transactions. It must return STATUS_VALID if all of the transactions could be executed without error. Note : The state transition rules have been modified such that deposits will never fail so if engine_forkchoiceUpdatedV2 returns STATUS_INVALID it is because a batched transaction is invalid. The gasLimit is optional w.r.t. compatibility with L1, but required when used as rollup. This field overrides the gas limit used during block-building. If not specified as rollup, a STATUS_INVALID is returned.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV2","id":"100","title":"engine_forkchoiceUpdatedV2"},"101":{"body":"See engine_forkchoiceUpdatedV2 for a description of the forkchoice updated method. engine_forkchoiceUpdatedV3 must only be called with Ecotone payload. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV3 : the extended PayloadAttributesV3 Extended PayloadAttributesV3 PayloadAttributesV3 is extended to: PayloadAttributesV3: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 parentBeaconBlockRoot: DATA (32 bytes) transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The requirements of this object are the same as extended PayloadAttributesV2 with the addition of parentBeaconBlockRoot which is the parent beacon block root from the L1 origin block of the L2 block. Starting at Ecotone, the parentBeaconBlockRoot must be set to the L1 origin parentBeaconBlockRoot, or a zero bytes32 if the Dencun functionality with parentBeaconBlockRoot is not active on L1.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV3","id":"101","title":"engine_forkchoiceUpdatedV3"},"102":{"body":"No modifications to engine_newPayloadV2 . Applies a L2 block to the engine state.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV2","id":"102","title":"engine_newPayloadV2"},"103":{"body":"engine_newPayloadV3 applies an Ecotone L2 block to the engine state. There are no modifications to this API. engine_newPayloadV3 must only be called with Ecotone payload. The additional parameters should be set as follows: expectedBlobVersionedHashes MUST be an empty array. parentBeaconBlockRoot MUST be the parent beacon block root from the L1 origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV3","id":"103","title":"engine_newPayloadV3"},"104":{"body":"No modifications to engine_getPayloadV2 . Retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV2 when called with payloadAttributes.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV2","id":"104","title":"engine_getPayloadV2"},"105":{"body":"engine_getPayloadV3 retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV3 when called with payloadAttributes. engine_getPayloadV3 must only be called with Ecotone payload. Extended Response The response is extended to: { executionPayload: ExecutionPayload blockValue: QUANTITY blobsBundle: BlobsBundle shouldOverrideBuilder: BOOLEAN parentBeaconBlockRoot: DATA (32 bytes)\n} In Ecotone it MUST be set to the parentBeaconBlockRoot from the L1 Origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV3","id":"105","title":"engine_getPayloadV3"},"106":{"body":"Optional extension to the Engine API. Signals superchain information to the Engine: V1 signals which protocol version is recommended and required. Types: SuperchainSignal: { recommended: ProtocolVersion; required: ProtocolVersion;\n} ProtocolVersion: encoded for RPC as defined in Protocol Version format specification . Parameters: signal: SuperchainSignal, the signaled superchain information. Returns: ProtocolVersion: the latest supported OP-Stack protocol version of the execution engine. The execution engine SHOULD warn the user when the recommended version is newer than the current version supported by the execution engine. The execution engine SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the execution engine operator.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_signalSuperchainV1","id":"106","title":"engine_signalSuperchainV1"},"107":{"body":"The execution engine can acquire all data through the rollup node, as derived from L1: P2P networking is strictly optional. However, to not bottleneck on L1 data retrieval speed, the P2P network functionality SHOULD be enabled, serving: Peer discovery ( Disc v5 ) eth/66 : Transaction pool (consumed by sequencer nodes) State sync (happy-path for fast trustless db replication) Historical block header and body retrieval New blocks are acquired through the consensus layer instead (rollup node) No modifications to L1 network functionality are required, except configuration: networkID : Distinguishes the L2 network from L1 and testnets. Equal to the chainID of the rollup network. Activate Merge fork: Enables Engine API and disables propagation of blocks, as block headers cannot be authenticated without consensus layer. Bootnode list: DiscV5 is a shared network, bootstrap is faster through connecting with L2 nodes first.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Networking","id":"107","title":"Networking"},"108":{"body":"The execution engine can operate sync in different ways: Happy-path: rollup node informs engine of the desired chain head as determined by L1, completes through engine P2P. Worst-case: rollup node detects stalled engine, completes sync purely from L1 data, no peers required. The happy-path is more suitable to bring new nodes online quickly, as the engine implementation can sync state faster through methods like snap-sync .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Sync","id":"108","title":"Sync"},"109":{"body":"The rollup node informs the engine of the L2 chain head, unconditionally (part of regular node operation): Bedrock / Canyon / Delta Payloads engine_newPayloadV2 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV2 is called with the current unsafe/safe/finalized L2 block hashes. Ecotone Payloads engine_newPayloadV3 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV3 is called with the current unsafe/safe/finalized L2 block hashes. The engine requests headers from peers, in reverse till the parent hash matches the local chain The engine catches up: a) A form of state sync is activated towards the finalized or head block hash b) A form of block sync pulls block bodies and processes towards head block hash The exact P2P based sync is out of scope for the L2 specification: the operation within the engine is the exact same as with L1 (although with an EVM that supports deposits).","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Happy-path sync","id":"109","title":"Happy-path sync"},"11":{"body":"Liveness is defined as the ability for any party to be able to extend the rollup chain by including a transaction within a bounded amount of time. It should not be possible for an actor to block the inclusion of any given transaction for more than this bounded time period. This bounded time period should also be acceptable such that inclusion is not just theoretically possible but practically useful.","breadcrumbs":"Background » Liveness","id":"11","title":"Liveness"},"110":{"body":"Engine is out of sync, not peered and/or stalled due other reasons. The rollup node maintains latest head from engine (poll eth_getBlockByNumber and/or maintain a header subscription) The rollup node activates sync if the engine is out of sync but not syncing through P2P (eth_syncing) The rollup node inserts blocks, derived from L1, one by one, potentially adapting to L1 reorg(s), as outlined in the rollup node spec .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Worst-case sync","id":"110","title":"Worst-case sync"},"111":{"body":"EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction, plus a list of \"blobs\": \"Binary Large Object\", i.e. a dedicated data type for serving Data-Availability as base-layer. With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception: as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type. EIP-4844 is disabled as following: Transaction network-layer announcements, announcing blob-type transactions, are ignored. Transactions of the blob-type, through the RPC or otherwise, are not allowed into the transaction pool. Block-building code does not select EIP-4844 transactions. An L2 block state-transition with EIP-4844 transactions is invalid. The BLOBBASEFEE opcode is present but its semantics are altered because there are no blobs processed by L2. The opcode will always push a value of 1 onto the stack.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: disable Blob-transactions","id":"111","title":"Ecotone: disable Blob-transactions"},"112":{"body":"EIP-4788 introduces a \"beacon block root\" into the execution-layer block-header and EVM. This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block. With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO of L1. And thus with EIP-4788 the L1 beacon block root is made available. For the Ecotone upgrade, this entails that: The parent_beacon_block_root of the L1 origin is now embedded in the L2 block header. The \"Beacon roots contract\" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis. The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: Beacon Block Root","id":"112","title":"Ecotone: Beacon Block Root"},"113":{"body":"The Ethereum Node Record (ENR) for an Optimism execution node must contain an opel key-value pair where the key is opel and the value is a EIP-2124 fork id. The EL uses a different key from the CL in order to stop EL and CL nodes from connecting to each other.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » P2P Modifications","id":"113","title":"P2P Modifications"},"114":{"body":"Table of Contents Overview Driver Derivation L2 Output RPC method Structures BlockID L1BlockRef L2BlockRef SyncStatus Output Method API Protocol Version tracking","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node Specification","id":"114","title":"Rollup Node Specification"},"115":{"body":"The rollup node is the component responsible for deriving the L2 chain from L1 blocks (and their associated receipts ). The part of the rollup node that derives the L2 chain is called the rollup driver . This document is currently only concerned with the specification of the rollup driver.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Overview","id":"115","title":"Overview"},"116":{"body":"The task of the driver in the rollup node is to manage the derivation process: Keep track of L1 head block Keep track of the L2 chain sync progress Iterate over the derivation steps as new inputs become available","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Driver","id":"116","title":"Driver"},"117":{"body":"This process happens in three steps: Select inputs from the L1 chain, on top of the last L2 block: a list of blocks, with transactions and associated data and receipts. Read L1 information, deposits, and sequencing batches in order to generate payload attributes (essentially a block without output properties ). Pass the payload attributes to the execution engine , so that the L2 block (including output block properties ) may be computed. While this process is conceptually a pure function from the L1 chain to the L2 chain, it is in practice incremental. The L2 chain is extended whenever new L1 blocks are added to the L1 chain. Similarly, the L2 chain re-organizes whenever the L1 chain re-organizes . For a complete specification of the L2 block derivation, refer to the L2 block derivation document .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation","id":"117","title":"Derivation"},"118":{"body":"The Rollup node has its own RPC method, optimism_outputAtBlock which returns a 32 byte hash corresponding to the L2 output root .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » L2 Output RPC method","id":"118","title":"L2 Output RPC method"},"119":{"body":"These define the types used by rollup node API methods. The types defined here are extended from the engine API specs . BlockID hash: DATA, 32 Bytes number: QUANTITY, 64 Bits L1BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits L2BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits l1origin: BlockID sequenceNumber: QUANTITY, 64 Bits - distance to first block of epoch SyncStatus Represents a snapshot of the rollup driver. current_l1: Object - instance of L1BlockRef . current_l1_finalized: Object - instance of L1BlockRef . head_l1: Object - instance of L1BlockRef . safe_l1: Object - instance of L1BlockRef . finalized_l1: Object - instance of L1BlockRef . unsafe_l2: Object - instance of L2BlockRef . safe_l2: Object - instance of L2BlockRef . finalized_l2: Object - instance of L2BlockRef . pending_safe_l2: Object - instance of L2BlockRef . queued_unsafe_l2: Object - instance of L2BlockRef .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Structures","id":"119","title":"Structures"},"12":{"body":"Validity is defined as the ability for any party to execute the rollup state transition function, subject to certain lower bound expectations for available computing and bandwidth resources. Validity is also extended to refer to the ability for a smart contract on Ethereum to be able to validate this state transition function economically.","breadcrumbs":"Background » Validity","id":"12","title":"Validity"},"120":{"body":"The input and return types here are as defined by the engine API specs . method: optimism_outputAtBlock params: blockNumber: QUANTITY, 64 bits - L2 integer block number. returns: version: DATA, 32 Bytes - the output root version number, beginning with 0. outputRoot: DATA, 32 Bytes - the output root. blockRef: Object - instance of L2BlockRef . withdrawalStorageRoot: 32 bytes - storage root of the L2toL1MessagePasser contract. stateRoot: DATA: 32 bytes - the state root. syncStatus: Object - instance of SyncStatus .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Output Method API","id":"120","title":"Output Method API"},"121":{"body":"The rollup-node should monitor the recommended and required protocol version by monitoring the Protocol Version contract on L1, as specified in the Superchain Version Signaling specifications . This can be implemented through polling in the Driver loop. After polling the Protocol Version, the rollup node SHOULD communicate it with the execution-engine through an engine_signalSuperchainV1 call. The rollup node SHOULD warn the user when the recommended version is newer than the current version supported by the rollup node. The rollup node SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the rollup node operator.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Protocol Version tracking","id":"121","title":"Protocol Version tracking"},"122":{"body":"Table of Contents Overview P2P configuration Identification Discv5 Consensus Layer Structure LibP2P Transport Dialing NAT Peer management Transport security Protocol negotiation Identify Ping Multiplexing GossipSub Content-based message identification Message compression and limits Message ID computation Heartbeat and parameters Topic configuration Topic validation Gossip Topics blocksv1 blocksv2 blocksv3 Block encoding Block signatures Block validation Block processing Block topic scoring parameters Req-Resp payload_by_number","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Rollup-node P2P interface","id":"122","title":"Rollup-node P2P interface"},"123":{"body":"The rollup node has an optional peer-to-peer (P2P) network service to improve the latency between the view of sequencers and the rest of the network by bypassing the L1 in the happy case, without relying on a single centralized endpoint. This also enables faster historical sync to be bootstrapped by providing block headers to sync towards, and only having to compare the L2 chain inputs to the L1 data as compared to processing everything one block at a time. The rollup node will always prioritize L1 and reorganize to match the canonical chain. The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the \"unsafe\" chain, to improve the happy case performance. This also means that P2P behavior is a soft-rule: nodes keep each other in check with scoring and eventual banning of malicious peers by identity or IP. Any behavior on the P2P layer does not affect the rollup security, at worst nodes rely on higher-latency data from L1 to serve. In summary, the P2P stack looks like: Discovery to find peers: Discv5 Connections, peering, transport security, multiplexing, gossip: LibP2P Application-layer publishing and validation of gossiped messages like L2 blocks. This document only specifies the composition and configuration of these network libraries. These components have their own standards, implementations in Go/Rust/Java/Nim/JS/more, and are adopted by several other blockchains, most notably the L1 consensus layer (Eth2) .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Overview","id":"123","title":"Overview"},"124":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » P2P configuration","id":"124","title":"P2P configuration"},"125":{"body":"Nodes have a separate network- and consensus-identity. The network identity is a secp256k1 key, used for both discovery and active LibP2P connections. Common representations of network identity: PeerID: a LibP2P specific ID derived from the pubkey (through protobuf encoding, typing and hashing) NodeID: a Discv5 specific ID derived from the pubkey (through hashing, used in the DHT) Multi-address: an unsigned address, containing: IP, TCP port, PeerID ENR: a signed record used for discovery, containing: IP, TCP port, UDP port, signature (pubkey can be derived) and L2 network identification. Generally encoded in base64.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Identification","id":"125","title":"Identification"},"126":{"body":"Consensus Layer Structure The Ethereum Node Record (ENR) for an Optimism rollup node must contain the following values, identified by unique keys: An IPv4 address (ip field) and/or IPv6 address (ip6 field). A TCP port (tcp field) representing the local libp2p listening port. A UDP port (udp field) representing the local discv5 listening port. An OpStack (opstack field) L2 network identifier The opstack value is encoded as a single RLP bytes value, the concatenation of: chain ID (unsigned varint) fork ID (unsigned varint) Note that DiscV5 is a shared DHT (Distributed Hash Table): the L1 consensus and execution nodes, as well as testnet nodes, and even external IOT nodes, all communicate records in this large common DHT. This makes it more difficult to censor the discovery of node records. The discovery process in Optimism is a pipeline of node records: Fill the table with FINDNODES if necessary (Performed by Discv5 library) Pull additional records with searches to random Node IDs if necessary (e.g. iterate RandomNodes() in Go implementation) Pull records from the DiscV5 module when looking for peers Check if the record contains the opstack entry, verify it matches the chain ID and current or future fork number If not already connected, and not recently disconnected or put on deny-list, attempt to dial.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Discv5","id":"126","title":"Discv5"},"127":{"body":"Transport TCP transport. Additional transports are supported by LibP2P, but not required. Dialing Nodes should be publicly dialable, not rely on relay extensions, and able to dial both IPv4 and IPv6. NAT The listening endpoint must be publicly facing, but may be configured behind a NAT. LibP2P will use PMP / UPNP based techniques to track the external IP of the node. It is recommended to disable the above if the external IP is static and configured manually. Peer management The default is to maintain a peer count with a tide-system based on active peer count: At \"low tide\" the node starts to actively search for additional peer connections. At \"high tide\" the node starts to prune active connections, except those that are marked as trusted or have a grace period. Peers will have a grace period for a configurable amount of time after joining. In an emergency, when memory runs low, the node should start pruning more aggressively. Peer records can be persisted to disk to quickly reconnect with known peers after restarting the rollup node. The discovery process feeds the peerstore with peer records to connect to, tagged with a time-to-live (TTL). The current P2P processes do not require selective topic-specific peer connections, other than filtering for the basic network participation requirement. Peers may be banned if their performance score is too low, or if an objectively malicious action was detected. Banned peers will be persisted to the same data-store as the peerstore records. TODO: the connection gater does currently not gate by IP address on the dial Accept-callback. Transport security Libp2p-noise , XX handshake, with the secp256k1 P2P identity, as popularized in Eth2. The TLS option is available as well, but noise should be prioritized in negotiation. Protocol negotiation Multistream-select 1.0 (/multistream/1.0.0) is an interactive protocol used to negotiate sub-protocols supported in LibP2P peers. Multistream-select 2.0 may be used in the future. Identify LibP2P offers a minimal identification module to share client version and programming language. This is optional and can be disabled for enhanced privacy. It also includes the same protocol negotiation information, which can speed up initial connections. Ping LibP2P includes a simple ping protocol to track latency between connections. This should be enabled to help provide insight into the network health. Multiplexing For async communication over different channels over the same connection, multiplexing is used. mplex (/mplex/6.7.0) is required, and yamux (/yamux/1.0.0) is recommended but optional GossipSub GossipSub 1.1 (/meshsub/1.1.0, i.e. with peer-scoring extension) is a pubsub protocol for mesh-networks, deployed on L1 consensus (Eth2) and other protocols such as Filecoin, offering lots of customization options. Content-based message identification Messages are deduplicated, and filtered through application-layer signature verification. Thus origin-stamping is disabled and published messages must only contain application data, enforced through a StrictNoSign Signature Policy This provides greater privacy, and allows sequencers (consensus identity) to maintain multiple network identities for redundancy. Message compression and limits The application contents are compressed with snappy single-block-compression (as opposed to frame-compression), and constrained to 10 MiB. Message ID computation Same as L1 , with recognition of compression: If message.data has a valid snappy decompression, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_VALID_SNAPPY with the snappy decompressed message data, i.e. SHA256(MESSAGE_DOMAIN_VALID_SNAPPY + snappy_decompress(message.data))[:20]. Otherwise, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_INVALID_SNAPPY with the raw message data, i.e. SHA256(MESSAGE_DOMAIN_INVALID_SNAPPY + message.data)[:20]. Heartbeat and parameters GossipSub parameters : D (topic stable mesh target count): 8 D_low (topic stable mesh low watermark): 6 D_high (topic stable mesh high watermark): 12 D_lazy (gossip target): 6 heartbeat_interval (interval of heartbeat, in seconds): 0.5 fanout_ttl (ttl for fanout maps for topics we are not subscribed to but have published to, in seconds): 24 mcache_len (number of windows to retain full messages in cache for IWANT responses): 12 mcache_gossip (number of windows to gossip about): 3 seen_ttl (number of heartbeat intervals to retain message IDs): 130 (= 65 seconds) Notable differences from L1 consensus (Eth2): seen_ttl does not need to cover a full L1 epoch (6.4 minutes), but rather just a small window covering latest blocks fanout_ttl: adjusted to lower than seen_ttl mcache_len: a larger number of heartbeats can be retained since the gossip is much less noisy. heartbeat_interval: faster interval to reduce latency, bandwidth should still be reasonable since there are far fewer messages to gossip about each interval than on L1 which uses an interval of 0.7 seconds. Topic configuration Topics have string identifiers and are communicated with messages and subscriptions. /optimism/chain_id/hardfork_version/Name chain_id: replace with decimal representation of chain ID hardfork_version: replace with decimal representation of hardfork, starting at 0 Name: topic application-name Note that the topic encoding depends on the topic, unlike L1, since there are less topics, and all are snappy-compressed. Topic validation To ensure only valid messages are relayed, and malicious peers get scored based on application behavior, an extended validator checks the message before it is relayed or processed. The extended validator emits one of the following validation signals: ACCEPT valid, relayed to other peers and passed to local topic subscriber IGNORE scored like inactivity, message is dropped and not processed REJECT score penalties, message is dropped","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » LibP2P","id":"127","title":"LibP2P"},"128":{"body":"There are three topics for distributing blocks to other nodes faster than proxying through L1 would. These are:","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Gossip Topics","id":"128","title":"Gossip Topics"},"129":{"body":"Pre-Canyon/Shanghai blocks are broadcast on /optimism//0/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv1","id":"129","title":"blocksv1"},"13":{"body":"Availability is defined as the ability for any party to retrieve the inputs that are necessary to execute the rollup state transition function correctly. Availability is essentially an element of validity and is required to be able to guarantee validity in general. Similar to validity, availability is subject to lower bound resource requirements.","breadcrumbs":"Background » Availability","id":"13","title":"Availability"},"130":{"body":"Canyon/Delta blocks are broadcast on /optimism//1/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv2","id":"130","title":"blocksv2"},"131":{"body":"Ecotone blocks are broadcast on /optimism//2/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv3","id":"131","title":"blocksv3"},"132":{"body":"A block is structured as the concatenation of: V1 and V2 topics signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. V3 topic signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) parentBeaconBlockRoot: L1 origin parent beacon block root, always 32 bytes payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. All topics use Snappy block-compression (i.e. no snappy frames): the above needs to be compressed after encoding, and decompressed before decoding.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block encoding","id":"132","title":"Block encoding"},"133":{"body":"The signature is a secp256k1 signature, and signs over a message: keccak256(domain ++ chain_id ++ payload_hash), where: domain is 32 bytes, reserved for message types and versioning info. All zero for this signature. chain_id is a big-endian encoded uint256. payload_hash is keccak256(payload), where payload is the payload in V1 and V2, and parentBeaconBlockRoot ++ payload in V3. The secp256k1 signature must have y_parity = 1 or 0, the chain_id is already signed over.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block signatures","id":"133","title":"Block signatures"},"134":{"body":"An extended-validator checks the incoming messages as follows, in order of operation: [REJECT] if the compression is not valid [REJECT] if the block encoding is not valid [REJECT] if the payload.timestamp is older than 60 seconds in the past (graceful boundary for worst-case propagation and clock skew) [REJECT] if the payload.timestamp is more than 5 seconds into the future [REJECT] if the block_hash in the payload is not valid [REJECT] if the block is on the V1 topic and has withdrawals [REJECT] if the block is on the V1 topic and has a withdrawals list [REJECT] if the block is on a topic >= V2 and does not have an empty withdrawals list [REJECT] if the block is on a topic <= V2 and has a blob gas-used value set [REJECT] if the block is on a topic <= V2 and has an excess blob gas value set [REJECT] if the block is on a topic >= V3 and has a blob gas-used value that is not zero [REJECT] if the block is on a topic >= V3 and has an excess blob gas value that is not zero [REJECT] if the block is on a topic <= V2 and the parent beacon block root is not nil [REJECT] if the block is on a topic >= V3 and the parent beacon block root is nil [REJECT] if more than 5 different blocks have been seen with the same block height [IGNORE] if the block has already been seen [REJECT] if the signature by the sequencer is not valid Mark the block as seen for the given block height The block is signed by the corresponding sequencer, to filter malicious messages. The sequencer model is singular but may change to multiple sequencers in the future. A default sequencer pubkey is distributed with rollup nodes and should be configurable. Note that blocks that a block may still be propagated even if the L1 already confirmed a different block. The local L1 view of the node may be wrong, and the time and signature validation will prevent spam. Hence, calling into the execution engine with a block lookup every propagation step is not worth the added delay. Block processing A node may apply the block to their local engine ahead of L1 availability, if it ensures that: The application of the block is reversible, in case of a conflict with delayed L1 information The subsequent forkchoice-update ensures this block is recognized as \"unsafe\" (see fork choice updated ) Block topic scoring parameters TODO: GossipSub per-topic scoring to fine-tune incentives for ideal propagation delay and bandwidth usage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block validation","id":"134","title":"Block validation"},"135":{"body":"The op-node implements a similar request-response encoding for its sync protocols as the L1 ethereum Beacon-Chain. See L1 P2P-interface req-resp specification and Altair P2P update . However, the protocol is simplified, to avoid several issues seen in L1: Error strings in responses, if there is any alternative response, should not need to be compressed or have an artificial global length limit. Payload lengths should be fixed-length: byte-by-byte uvarint reading from the underlying stream is undesired. are relaxed to encode a uint32, rather than a beacon-chain ForkDigest. Payload-encoding may change per hardfork, so is not part of the protocol-ID. Usage of response-chunks is specific to the req-resp method: most basic req-resp does not need chunked responses. Compression is encouraged to be part of the payload-encoding, specific to the req-resp method, where necessary: pings and such do not need streaming frame compression etc. And the protocol ID format follows the same scheme as L1, except the trailing encoding schema part, which is now message-specific: /ProtocolPrefix/MessageName/SchemaVersion/ The req-resp protocols served by the op-node all have /ProtocolPrefix set to /opstack/req. Individual methods may include the chain ID as part of the /MessageName segment, so it's immediately clear which chain the method applies to, if the communication is chain-specific. Other methods may include chain-information in the request and/or response data, such as the ForkDigest in L1 beacon chain req-resp protocols. Each segment starts with a /, and may contain multiple /, and the final protocol ID is suffixed with a /.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Req-Resp","id":"135","title":"Req-Resp"},"136":{"body":"This is an optional chain syncing method, to request/serve execution payloads by number. This serves as a method to fill gaps upon missed gossip, and sync short to medium ranges of unsafe L2 blocks. Protocol ID: /opstack/req/payload_by_number//0/ /MessageName is /block_by_number/ where is set to the op-node L2 chain ID. /SchemaVersion is /0 Request format: : a little-endian uint64 - the block number to request. Response format: = is a byte code describing the result. 0 on success, should follow. 1 if valid request, but unavailable payload. 2 if invalid request 3+ if other error The >= 128 range is reserved for future use. is a little-endian uint32, identifying the response type (fork-specific) is an encoded block, read till stream EOF. The input of should be limited, as well as any generated decompressed output, to avoid unexpected resource usage or zip-bomb type attacks. A 10 MB limit is recommended, to ensure all blocks may be synced. Implementations may opt for a different limit, since this sync method is optional. list: 0: SSZ-encoded ExecutionPayload, with Snappy framing compression, matching the ExecutionPayload SSZ definition of the L1 Merge, L2 Bedrock and L2 Regolith, L2 Canyon versions. 1: SSZ-encoded ExecutionPayloadEnvelope with Snappy framing compression, matching the ExecutionPayloadEnvelope SSZ definition of the L2 Ecotone version. The request is by block-number, enabling parallel fetching of a chain across many peers. A res = 0 response should be verified to: Have a block-number matching the requested block number. Have a consistent blockhash w.r.t. the other block contents. Build towards a known canonical block. This can be verified by checking if the parent-hash of a previous trusted canonical block matches that of the verified hash of the retrieved block. For unsafe blocks this may be relaxed to verification against the parent-hash of any previously trusted block: The gossip validation process limits the amount of blocks that may be trusted to sync towards. The unsafe blocks should be queued for processing, the latest received L2 unsafe blocks should always override any previous chain, until the final L2 chain can be reproduced from L1 data. A res > 0 response code should not be accepted. The result code is helpful for debugging, but the client should regard any error like any other unanswered request, as the responding peer cannot be trusted.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » payload_by_number","id":"136","title":"payload_by_number"},"137":{"body":"Table of Contents Overview Eager Block Derivation Protocol Parameters Batch Submission Sequencing & Batch Submission Overview Batch Submission Wire Format Batcher Transaction Format Frame Format Channel Format Batch Format Architecture L2 Chain Derivation Pipeline L1 Traversal L1 Retrieval Frame Queue Channel Bank Pruning Timeouts Reading Loading frames Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue Engine API usage Bedrock, Canyon, Delta: API Usage Ecotone: API Usage Forkchoice synchronization L1-consolidation: payload attributes matching L1-sync: payload attributes processing Processing unsafe payload attributes Resetting the Pipeline Finding the sync starting point Resetting derivation stages About reorgs Post-Merge Deriving Payload Attributes Deriving the Transaction List Network upgrade automation transactions Ecotone L1Block Deployment GasPriceOracle Deployment L1Block Proxy Update GasPriceOracle Proxy Update GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) Building Individual Payload Attributes","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Specification","id":"137","title":"L2 Chain Derivation Specification"},"138":{"body":"Note the following assumes a single sequencer and batcher. In the future, the design will be adapted to accommodate multiple such entities. L2 chain derivation — deriving L2 blocks from L1 data — is one of the main responsibilities of the rollup node , both in validator mode, and in sequencer mode (where derivation acts as a sanity check on sequencing, and enables detecting L1 chain re-organizations ). The L2 chain is derived from the L1 chain. In particular, each L1 block following L2 chain inception is mapped to a sequencing epoch comprising at least one L2 block. Each L2 block belongs to exactly one epoch, and we call the corresponding L1 block its L1 origin . The epoch's number equals that of its L1 origin block. To derive the L2 blocks of epoch number E, we need the following inputs: L1 blocks in the range [E, E + SWS), called the sequencing window of the epoch, and SWS the sequencing window size. (Note that sequencing windows overlap.) Batcher transactions from blocks in the sequencing window. These transactions allow us to reconstruct the epoch's sequencer batches , each of which will produce one L2 block. Note that: The L1 origin will never contain any data needed to construct sequencer batches since each batch must contain the L1 origin hash. An epoch may have no sequencer batches. Deposits made in the L1 origin (in the form of events emitted by the deposit contract ). L1 block attributes from the L1 origin (to derive the L1 attributes deposited transaction ). The state of the L2 chain after the last L2 block of the previous epoch, or the L2 genesis state if E is the first epoch. To derive the whole L2 chain from scratch, we start with the L2 genesis state and the L2 genesis block as the first L2 block. We then derive L2 blocks from each epoch in order, starting at the first L1 block following L2 chain inception . Refer to the Architecture section for more information on how we implement this in practice. The L2 chain may contain pre-Bedrock history, but the L2 genesis here refers to the Bedrock L2 genesis block. Each L2 block with origin l1_origin is subject to the following constraints (whose values are denominated in seconds): block.timestamp = prev_l2_timestamp + l2_block_time prev_l2_timestamp is the timestamp of the L2 block immediately preceding this one. If there is no preceding block, then this is the genesis block, and its timestamp is explicitly specified. l2_block_time is a configurable parameter of the time between L2 blocks (2s on Optimism). l1_origin.timestamp <= block.timestamp <= max_l2_timestamp, where max_l2_timestamp = max(l1_origin.timestamp + max_sequencer_drift, prev_l2_timestamp + l2_block_time) max_sequencer_drift is a configurable parameter that bounds how far the sequencer can get ahead of the L1. Finally, each epoch must have at least one L2 block. The first constraint means there must be an L2 block every l2_block_time seconds following L2 chain inception. The second constraint ensures that an L2 block timestamp never precedes its L1 origin timestamp, and is never more than max_sequencer_drift ahead of it, except only in the unusual case where it might prohibit an L2 block from being produced every l2_block_time seconds. (Such cases might arise for example under a proof-of-work L1 that sees a period of rapid L1 block production.) In either case, the sequencer enforces len(batch.transactions) == 0 while max_sequencer_drift is exceeded. See Batch Queue for more details. The final requirement that each epoch must have at least one L2 block ensures that all relevant information from the L1 (e.g. deposits) is represented in the L2, even if it has no sequencer batches. Post-merge, Ethereum has a fixed 12s block time , though some slots can be skipped. Under a 2s L2 block time, we thus expect each epoch to typically contain 12/2 = 6 L2 blocks. The sequencer will however produce bigger epochs in order to maintain liveness in case of either a skipped slot on the L1 or a temporary loss of connection to it. For the lost connection case, smaller epochs might be produced after the connection was restored to keep L2 timestamps from drifting further and further ahead.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Overview","id":"138","title":"Overview"},"139":{"body":"Deriving an L2 block requires that we have constructed its sequencer batch and derived all L2 blocks and state updates prior to it. This means we can typically derive the L2 blocks of an epoch eagerly without waiting on the full sequencing window. The full sequencing window is required before derivation only in the very worst case where some portion of the sequencer batch for the first block of the epoch appears in the very last L1 block of the window. Note that this only applies to block derivation. Sequencer batches can still be derived and tentatively queued without deriving blocks from them.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Eager Block Derivation","id":"139","title":"Eager Block Derivation"},"14":{"body":"Generally speaking, there are three primary actors that interact with an OP Stack chain: users, sequencers, and verifiers. graph TD EthereumL1(Ethereum L1) subgraph \"L2 Participants\" Users(Users) Sequencers(Sequencers) Verifiers(Verifiers) end Verifiers -.->|fetch transaction batches| EthereumL1 Verifiers -.->|fetch deposit data| EthereumL1 Verifiers -->|submit/validate/challenge output proposals| EthereumL1 Verifiers -.->|fetch realtime P2P updates| Sequencers Users -->|submit deposits/withdrawals| EthereumL1 Users -->|submit transactions| Sequencers Users -->|query data| Verifiers Sequencers -->|submit transaction batches| EthereumL1 Sequencers -.->|fetch deposit data| EthereumL1 classDef l1Contracts stroke:#bbf,stroke-width:2px; classDef l2Components stroke:#333,stroke-width:2px; classDef systemUser stroke:#f9a,stroke-width:2px; class EthereumL1 l1Contracts; class Users,Sequencers,Verifiers l2Components;","breadcrumbs":"Background » Network Participants","id":"14","title":"Network Participants"},"140":{"body":"The following table gives an overview of some protocol parameters, and how they are affected by protocol upgrades. Parameter Bedrock (default) value Latest (default) value Changes Notes max_sequencer_drift 600 1800 Fjord Changed from a chain parameter to a constant with Fjord. MAX_RLP_BYTES_PER_CHANNEL 10,000,000 100,000,000 Fjord Constant increased with Fjord. MAX_CHANNEL_BANK_SIZE 100,000,000 1,000,000,000 Fjord Constant increased with Fjord. MAX_SPAN_BATCH_ELEMENT_COUNT 10,000,000 10,000,000 Effectively introduced in Fjord Number of elements","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Protocol Parameters","id":"140","title":"Protocol Parameters"},"141":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission","id":"141","title":"Batch Submission"},"142":{"body":"The sequencer accepts L2 transactions from users. It is responsible for building blocks out of these. For each such block, it also creates a corresponding sequencer batch . It is also responsible for submitting each batch to a data availability provider (e.g. Ethereum calldata), which it does via its batcher component. The difference between an L2 block and a batch is subtle but important: the block includes an L2 state root, whereas the batch only commits to transactions at a given L2 timestamp (equivalently: L2 block number). A block also includes a reference to the previous block (*). (*) This matters in some edge case where a L1 reorg would occur and a batch would be reposted to the L1 chain but not the preceding batch, whereas the predecessor of an L2 block cannot possibly change. This means that even if the sequencer applies a state transition incorrectly, the transactions in the batch will still be considered part of the canonical L2 chain. Batches are still subject to validity checks (i.e. they have to be encoded correctly), and so are individual transactions within the batch (e.g. signatures have to be valid). Invalid batches and invalid individual transactions within an otherwise valid batch are discarded by correct nodes. If the sequencer applies a state transition incorrectly and posts an output root , then this output root will be incorrect. The incorrect output root will be challenged by a fault proof , then replaced by a correct output root for the existing sequencer batches. Refer to the Batch Submission specification for more information.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Sequencing & Batch Submission Overview","id":"142","title":"Sequencing & Batch Submission Overview"},"143":{"body":"Batch submission is closely tied to L2 chain derivation because the derivation process must decode the batches that have been encoded for the purpose of batch submission. The batcher submits batcher transactions to a data availability provider . These transactions contain one or multiple channel frames , which are chunks of data belonging to a channel . A channel is a sequence of sequencer batches (for any L2 blocks) compressed together. The reason to group multiple batches together is simply to obtain a better compression rate, hence reducing data availability costs. Channels might be too large to fit in a single batcher transaction , hence we need to split it into chunks known as channel frames . A single batcher transaction can also carry multiple frames (belonging to the same or to different channels). This design gives use the maximum flexibility in how we aggregate batches into channels, and split channels over batcher transactions. It notably allows us to maximize data utilization in a batcher transaction: for instance it allows us to pack the final (small) frame of one channel with one or more frames from the next channel. Also note that we use a streaming compression scheme, and we do not need to know how many batches a channel will end up containing when we start a channel, or even as we send the first frames in the channel. And by splitting channels across multiple data transactions, the L2 can have larger block data than the data-availability layer may support. All of this is illustrated in the following diagram. Explanations below. batch derivation chain diagram The first line represents L1 blocks with their numbers. The boxes under the L1 blocks represent batcher transactions included within the block. The squiggles under the L1 blocks represent deposits (more specifically, events emitted by the deposit contract ). Each colored chunk within the boxes represents a channel frame . So A and B are channels whereas A0, A1, B0, B1, B2 are frames. Notice that: multiple channels are interleaved frames do not need to be transmitted in order a single batcher transaction can carry frames from multiple channels In the next line, the rounded boxes represent individual sequencer batches that were extracted from the channels. The four blue/purple/pink were derived from channel A while the other were derived from channel B. These batches are here represented in the order they were decoded from batches (in this case B is decoded first). Note The caption here says \"Channel B was seen first and will be decoded into batches first\", but this is not a requirement. For instance, it would be equally acceptable for an implementation to peek into the channels and decode the one that contains the oldest batches first. The rest of the diagram is conceptually distinct from the first part and illustrates L2 chain derivation after the channels have been reordered. The first line shows batcher transactions. Note that in this case, there exists an ordering of the batches that makes all frames within the channels appear contiguously. This is not true in general. For instance, in the second transaction, the position of A1 and B0 could have been inverted for exactly the same result — no changes needed in the rest of the diagram. The second line shows the reconstructed channels in proper order. The third line shows the batches extracted from the channel. Because the channels are ordered and the batches within a channel are sequential, this means the batches are ordered too. The fourth line shows the L2 block derived from each batch. Note that we have a 1-1 batch to block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there are \"gaps\" in the batches posted on L1. The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while the second number (the \"sequence number\") denotes the position within the epoch. Finally, the sixth line shows user-deposited transactions derived from the deposit contract event mentioned earlier. Note the 101-0 L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if frame B2 indicates that it is the last frame within the channel and (2) no empty blocks must be inserted. The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4 blocks, because the last frame of channel A appears in block 102, but belong to epoch 99. As for the comment on \"security types\", it explains the classification of blocks as used on L1 and L2. Unsafe L2 blocks : Safe L2 blocks : Finalized L2 blocks: refer to block that have been derived from finalized L1 data. These security levels map to the headBlockHash, safeBlockHash and finalizedBlockHash values transmitted when interacting with the execution-engine API .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission Wire Format","id":"143","title":"Batch Submission Wire Format"},"144":{"body":"Batcher transactions are encoded as version_byte ++ rollup_payload (where ++ denotes concatenation). version_byte rollup_payload 0 frame ... (one or more frames, concatenated) 1 da_commitment (experimental, see alt-da ) Unknown versions make the batcher transaction invalid (it must be ignored by the rollup node). All frames in a batcher transaction must be parseable. If any one frame fails to parse, the all frames in the transaction are rejected. Batch transactions are authenticated by verifying that the to address of the transaction matches the batch inbox address, and the from address matches the batch-sender address in the system configuration at the time of the L1 block that the transaction data is read from.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batcher Transaction Format","id":"144","title":"Batcher Transaction Format"},"145":{"body":"A channel frame is encoded as: frame = channel_id ++ frame_number ++ frame_data_length ++ frame_data ++ is_last channel_id = bytes16\nframe_number = uint16\nframe_data_length = uint32\nframe_data = bytes\nis_last = bool Where uint32 and uint16 are all big-endian unsigned integers. Type names should be interpreted to and encoded according to the Solidity ABI . All data in a frame is fixed-size, except the frame_data. The fixed overhead is 16 + 2 + 4 + 1 = 23 bytes. Fixed-size frame metadata avoids a circular dependency with the target total data length, to simplify packing of frames with varying content length. where: channel_id is an opaque identifier for the channel. It should not be reused and is suggested to be random; however, outside of timeout rules, it is not checked for validity frame_number identifies the index of the frame within the channel frame_data_length is the length of frame_data in bytes. It is capped to 1,000,000 bytes. frame_data is a sequence of bytes belonging to the channel, logically after the bytes from the previous frames is_last is a single byte with a value of 1 if the frame is the last in the channel, 0 if there are frames in the channel. Any other value makes the frame invalid (it must be ignored by the rollup node).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Format","id":"145","title":"Frame Format"},"146":{"body":"A channel is encoded by applying a streaming compression algorithm to a list of batches: rlp_batches = []\nfor batch in batches: rlp_batches.append(batch) where: batches is the input, a sequence of batches byte-encoded as per the next section (\"Batch Encoding\") rlp_batches is the concatenation of the RLP-encoded batches channel_encoding = zlib_compress(rlp_batches) where zlib_compress is the ZLIB algorithm (as specified in RFC-1950 ) with no dictionary. The Fjord upgrade introduces an additional versioned channel encoding format to support alternate compression algorithms. When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL (defined in the Protocol Parameters table ), in order to avoid \"zip-bomb\" types of attack (where a small compressed input decompresses to a humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained only the first MAX_RLP_BYTES_PER_CHANNEL decompressed bytes. The limit is set on RLP decoding, so all batches that can be decoded in MAX_RLP_BYTES_PER_CHANNEL will be accepted even if the size of the channel is greater than MAX_RLP_BYTES_PER_CHANNEL. The exact requirement is that length(input) <= MAX_RLP_BYTES_PER_CHANNEL. While the above pseudocode implies that all batches are known in advance, it is possible to perform streaming compression and decompression of RLP-encoded batches. This means it is possible to start including channel frames in a batcher transaction before we know how many batches (and how many frames) the channel will contain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Format","id":"146","title":"Channel Format"},"147":{"body":"Recall that a batch contains a list of transactions to be included in a specific L2 block. A batch is encoded as batch_version ++ content, where content depends on the batch_version. Prior to the Delta upgrade, batches all have batch_version 0 and are encoded as described below. batch_version content 0 rlp_encode([parent_hash, epoch_number, epoch_hash, timestamp, transaction_list]) where: batch_version is a single byte, prefixed before the RLP contents, alike to transaction typing. rlp_encode is a function that encodes a batch according to the RLP format , and [x, y, z] denotes a list containing items x, y and z parent_hash is the block hash of the previous L2 block epoch_number and epoch_hash are the number and hash of the L1 block corresponding to the sequencing epoch of the L2 block timestamp is the timestamp of the L2 block transaction_list is an RLP-encoded list of EIP-2718 encoded transactions. The Delta upgrade introduced an additional batch type, span batches . Unknown versions make the batch invalid (it must be ignored by the rollup node), as do malformed contents. The epoch_number and the timestamp must also respect the constraints listed in the Batch Queue section, otherwise the batch is considered invalid and will be ignored.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Format","id":"147","title":"Batch Format"},"148":{"body":"The above primarily describes the general encodings used in L2 chain derivation, primarily how batches are encoded within batcher transactions . This section describes how the L2 chain is produced from the L1 batches using a pipeline architecture. A verifier may implement this differently, but must be semantically equivalent to not diverge from the L2 chain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Architecture","id":"148","title":"Architecture"},"149":{"body":"Our architecture decomposes the derivation process into a pipeline made up of the following stages: L1 Traversal L1 Retrieval Frame Queue Channel Bank Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue The data flows from the start (outer) of the pipeline towards the end (inner). From the innermost stage the data is pulled from the outermost stage. However, data is processed in reverse order. Meaning that if there is any data to be processed in the last stage, it will be processed first. Processing proceeds in \"steps\" that can be taken at each stage. We try to take as many steps as possible in the last (most inner) stage before taking any steps in its outer stage, etc. This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing the derivation pipeline. Each stage can maintain its own inner state as necessary. In particular, each stage maintains a L1 block reference (number + hash) to the latest L1 block such that all data originating from previous blocks has been fully processed, and the data from that block is being or has been processed. This allows the innermost stage to account for finalization of the L1 data-availability used to produce the L2 chain, to reflect in the L2 chain forkchoice when the L2 chain inputs become irreversible. Let's briefly describe each stage of the pipeline.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Pipeline","id":"149","title":"L2 Chain Derivation Pipeline"},"15":{"body":"Users are the general class of network participants who: Submit transactions through a Sequencer or by interacting with contracts on Ethereum. Query transaction data from interfaces operated by verifiers.","breadcrumbs":"Background » Users","id":"15","title":"Users"},"150":{"body":"In the L1 Traversal stage, we simply read the header of the next L1 block. In normal operations, these will be new L1 blocks as they get created, though we can also read old blocks while syncing, or in case of an L1 re-org . Upon traversal of the L1 block, the system configuration copy used by the L1 retrieval stage is updated, such that the batch-sender authentication is always accurate to the exact L1 block that is read by the stage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Traversal","id":"150","title":"L1 Traversal"},"151":{"body":"In the L1 Retrieval stage, we read the block we get from the outer stage (L1 traversal), and extract data from its batcher transactions . A batcher transaction is one with the following properties: The to field is equal to the configured batcher inbox address. The sender, as recovered from the transaction signature (v, r, and s), is the batcher address loaded from the system config matching the L1 block of the data. Each batcher transaction is versioned and contains a series of channel frames to be read by the Frame Queue, see Batch Submission Wire Format . Each batcher transaction in the block is processed in the order they appear in the block by passing its calldata on to the next phase.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Retrieval","id":"151","title":"L1 Retrieval"},"152":{"body":"The Frame Queue buffers one data-transaction at a time, decoded into channel frames , to be consumed by the next stage. See Batcher transaction format and Frame format specifications.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Queue","id":"152","title":"Frame Queue"},"153":{"body":"The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1 retrieval stage. A step in the channel bank stage tries to read data from channels that are \"ready\". Channels are currently fully buffered until read or dropped, streaming channels may be supported in a future version of the ChannelBank. To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels. Channels are recorded in FIFO order in a structure called the channel queue . A channel is added to the channel queue the first time a frame belonging to the channel is seen. Pruning After successfully inserting a new frame, the ChannelBank is pruned: channels are dropped in FIFO order, until total_size <= MAX_CHANNEL_BANK_SIZE, where: total_size is the sum of the sizes of each channel, which is the sum of all buffered frame data of the channel, with an additional frame-overhead of 200 bytes per frame. MAX_CHANNEL_BANK_SIZE is a protocol constant defined in the Protocol Parameters table . Timeouts The L1 origin that the channel was opened in is tracked with the channel as channel.open_l1_block, and determines the maximum span of L1 blocks that the channel data is retained for, before being pruned. A channel is timed out if: current_l1_block.number > channel.open_l1_block.number + CHANNEL_TIMEOUT, where: current_l1_block is the L1 origin that the stage is currently traversing. CHANNEL_TIMEOUT is a rollup-configurable, expressed in number of L1 blocks. New frames for timed-out channels are dropped instead of buffered. Reading Upon reading, while the first opened channel is timed-out, remove it from the channel-bank. Prior to the Canyon network upgrade, once the first opened channel, if any, is not timed-out and is ready, then it is read and removed from the channel-bank. After the Canyon network upgrade, the entire channel bank is scanned in FIFO order (by open time) & the first ready (i.e. not timed-out) channel will be returned. The canyon behavior will activate when frames from a L1 block whose timestamp is greater than or equal to the canyon time first enter the channel queue. A channel is ready if: The channel is closed The channel has a contiguous sequence of frames until the closing frame If no channel is ready, the next frame is read and ingested into the channel bank. Loading frames When a channel ID referenced by a frame is not already present in the Channel Bank, a new channel is opened, tagged with the current L1 block, and appended to the channel-queue. Frame insertion conditions: New frames matching timed-out channels that have not yet been pruned from the channel-bank are dropped. Duplicate frames (by frame number) for frames that have not been pruned from the channel-bank are dropped. Duplicate closes (new frame is_last == 1, but the channel has already seen a closing frame and has not yet been pruned from the channel-bank) are dropped. If a frame is closing (is_last == 1) any existing higher-numbered frames are removed from the channel. Note that while this allows channel IDs to be reused once they have been pruned from the channel-bank, it is recommended that batcher implementations use unique channel IDs.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Bank","id":"153","title":"Channel Bank"},"154":{"body":"In this stage, we decompress the channel we pull from the last stage, and then parse batches from the decompressed byte stream. See Channel Format and Batch Format for decompression and decoding specification.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Reader (Batch Decoding)","id":"154","title":"Channel Reader (Batch Decoding)"},"155":{"body":"During the Batch Buffering stage, we reorder batches by their timestamps. If batches are missing for some time slots and a valid batch with a higher timestamp exists, this stage also generates empty batches to fill the gaps. Batches are pushed to the next stage whenever there is one sequential batch directly following the timestamp of the current safe L2 head (the last block that can be derived from the canonical L1 chain). The parent hash of the batch must also match the hash of the current safe L2 head. Note that the presence of any gaps in the batches derived from L1 means that this stage will need to buffer for a whole sequencing window before it can generate empty batches (because the missing batch(es) could have data in the last L1 block of the window in the worst case). A batch can have 4 different forms of validity: drop: the batch is invalid, and will always be in the future, unless we reorg. It can be removed from the buffer. accept: the batch is valid and should be processed. undecided: we are lacking L1 information until we can proceed batch filtering. future: the batch may be valid, but cannot be processed yet and should be checked again later. The batches are processed in order of the inclusion on L1: if multiple batches can be accept-ed the first is applied. An implementation can defer future batches a later derivation step to reduce validation work. The batches validity is derived as follows: Definitions: batch as defined in the Batch format section . epoch = safe_l2_head.l1_origin a L1 origin coupled to the batch, with properties: number (L1 block number), hash (L1 block hash), and timestamp (L1 block timestamp). inclusion_block_number is the L1 block number when batch was first fully derived, i.e. decoded and output by the previous stage. next_timestamp = safe_l2_head.timestamp + block_time is the expected L2 timestamp the next batch should have, see block time information . next_epoch may not be known yet, but would be the L1 block after epoch if available. batch_origin is either epoch or next_epoch, depending on validation. Note that processing of a batch can be deferred until batch.timestamp <= next_timestamp, since future batches will have to be retained anyway. Rules, in validation order: batch.timestamp > next_timestamp -> future: i.e. the batch must be ready to process. batch.timestamp < next_timestamp -> drop: i.e. the batch must not be too old. batch.parent_hash != safe_l2_head.hash -> drop: i.e. the parent hash must be equal to the L2 safe head block hash. batch.epoch_num + sequence_window_size < inclusion_block_number -> drop: i.e. the batch must be included timely. batch.epoch_num < epoch.number -> drop: i.e. the batch origin is not older than that of the L2 safe head. batch.epoch_num == epoch.number: define batch_origin as epoch. batch.epoch_num == epoch.number+1: If next_epoch is not known -> undecided: i.e. a batch that changes the L1 origin cannot be processed until we have the L1 origin data. If known, then define batch_origin as next_epoch batch.epoch_num > epoch.number+1 -> drop: i.e. the L1 origin cannot change by more than one L1 block per L2 block. batch.epoch_hash != batch_origin.hash -> drop: i.e. a batch must reference a canonical L1 origin, to prevent batches from being replayed onto unexpected L1 chains. batch.timestamp < batch_origin.time -> drop: enforce the min L2 timestamp rule. batch.timestamp > batch_origin.time + max_sequencer_drift: enforce the L2 timestamp drift rule, but with exceptions to preserve above min L2 timestamp invariant: len(batch.transactions) == 0: epoch.number == batch.epoch_num: this implies the batch does not already advance the L1 origin, and must thus be checked against next_epoch. If next_epoch is not known -> undecided: without the next L1 origin we cannot yet determine if time invariant could have been kept. If batch.timestamp >= next_epoch.time -> drop: the batch could have adopted the next L1 origin without breaking the L2 time >= L1 time invariant. len(batch.transactions) > 0: -> drop: when exceeding the sequencer time drift, never allow the sequencer to include transactions. batch.transactions: drop if the batch.transactions list contains a transaction that is invalid or derived by other means exclusively: any transaction that is empty (zero length byte string) any deposited transactions (identified by the transaction type prefix byte) If no batch can be accept-ed, and the stage has completed buffering of all batches that can fully be read from the L1 block at height epoch.number + sequence_window_size, and the next_epoch is available, then an empty batch can be derived with the following properties: parent_hash = safe_l2_head.hash timestamp = next_timestamp transactions is empty, i.e. no sequencer transactions. Deposited transactions may be added in the next stage. If next_timestamp < next_epoch.time: the current L1 origin is repeated, to preserve the L2 time invariant. epoch_num = epoch.number epoch_hash = epoch.hash If the batch is the first batch of the epoch, that epoch is used instead of advancing the epoch to ensure that there is at least one L2 block per epoch. epoch_num = epoch.number epoch_hash = epoch.hash Otherwise, epoch_num = next_epoch.number epoch_hash = next_epoch.hash","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Queue","id":"155","title":"Batch Queue"},"156":{"body":"In the Payload Attributes Derivation stage, we convert the batches we get from the previous stage into instances of the PayloadAttributes structure. Such a structure encodes the transactions that need to figure into a block, as well as other block inputs (timestamp, fee recipient, etc). Payload attributes derivation is detailed in the section Deriving Payload Attributes section below. This stage maintains its own copy of the system configuration , independent of the L1 retrieval stage. The system configuration is updated with L1 log events whenever the L1 epoch referenced by the batch input changes.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Payload Attributes Derivation","id":"156","title":"Payload Attributes Derivation"},"157":{"body":"In the Engine Queue stage, the previously derived PayloadAttributes structures are buffered and sent to the execution engine to be executed and converted into a proper L2 block. The stage maintains references to three L2 blocks: The finalized L2 head : everything up to and including this block can be fully derived from the finalized (i.e. canonical and forever irreversible) part of the L1 chain. The safe L2 head : everything up to and including this block can be fully derived from the currently canonical L1 chain. The unsafe L2 head : blocks between the safe and unsafe heads are unsafe blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer mode) or from unsafe sync to the sequencer (in validator mode). This is also known as the \"latest\" head. Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references from which L1 blocks each was derived. This history does not have to be complete, but enables later L1 finality signals to be translated into L2 finality. Engine API usage To interact with the engine, the execution engine API is used, with the following JSON-RPC methods: Bedrock, Canyon, Delta: API Usage engine_forkchoiceUpdatedV2 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV2 — retrieves a previously requested execution payload build. engine_newPayloadV2 — executes an execution payload to create a block. Ecotone: API Usage engine_forkchoiceUpdatedV3 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV3 — retrieves a previously requested execution payload build. engine_newPayload engine_newPayloadV2 — executes a Bedrock/Canyon/Delta execution payload to create a block. engine_newPayloadV3 — executes an Ecotone execution payload to create a block. The current version of op-node uses the v3 Engine API RPC methods as well as engine_newPayloadV2, due to engine_newPayloadV3 only supporting Ecotone execution payloads. Both engine_forkchoiceUpdatedV3 and engine_getPayloadV3 are backwards compatible with Bedrock, Canyon & Delta payloads. Prior versions of op-node used v2 and v1 methods. The execution payload is an object of type ExecutionPayloadV3 . The ExecutionPayload has the following requirements: Bedrock The withdrawals field MUST be nil The blob gas used field MUST be nil The blob gas limit field MUST be nil Canyon, Delta The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be nil The blob gas limit field MUST be nil Ecotone The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be 0 The blob gas limit field MUST be 0 Forkchoice synchronization If there are any forkchoice updates to be applied, before additional inputs are derived or processed, then these are applied to the engine first. This synchronization may happen when: A L1 finality signal finalizes one or more L2 blocks: updating the \"finalized\" L2 block. A successful consolidation of unsafe L2 blocks: updating the \"safe\" L2 block. The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state. The new forkchoice state is applied by calling fork choice updated on the engine API. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. L1-consolidation: payload attributes matching If the unsafe head is ahead of the safe head, then consolidation is attempted, verifying that existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data. During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If the payload attributes match this oldest unsafe L2 block, then that block can be considered \"safe\" and becomes the new safe head. The following fields of the derived L2 payload attributes are checked for equality with the L2 block: Bedrock, Canyon, Delta, Ecotone Blocks parent_hash timestamp randao fee_recipient transactions_list (first length, then equality of each of the encoded transactions, including deposits) gas_limit Canyon, Delta, Ecotone Blocks withdrawals (first presence, then length, then equality of each of the encoded withdrawals) Ecotone Blocks parent_beacon_block_root If consolidation succeeds, the forkchoice change will synchronize as described in the section above. If consolidation fails, the L2 payload attributes will be processed immediately as described in the section below. The payload attributes are chosen in favor of the previous unsafe L2 block, creating an L2 chain reorg on top of the current safe block. Immediately processing the new alternative attributes enables execution engines like go-ethereum to enact the change, as linear rewinds of the tip of the chain may not be supported. L1-sync: payload attributes processing If the safe and unsafe L2 heads are identical (whether because of failed consolidation or not), we send the L2 payload attributes to the execution engine to be constructed into a proper L2 block. This L2 block will then become both the new L2 safe and unsafe head. If a payload attributes created from a batch cannot be inserted into the chain because of a validation error (i.e. there was an invalid transaction or state transition in the block) the batch should be dropped & the safe head should not be advanced. The engine queue will attempt to use the next batch for that timestamp from the batch queue. If no valid batch is found, the rollup node will create a deposit only batch which should always pass validation because deposits are always valid. Interaction with the execution engine via the execution engine API is detailed in the Communication with the Execution Engine section. The payload attributes are then processed with a sequence of: Engine: Fork choice updated with current forkchoice state of the stage, and the attributes to start block building. Non-deterministic sources, like the tx-pool, must be disabled to reconstruct the expected block. Engine: Get Payload to retrieve the payload, by the payload-ID in the result of the previous step. Engine: New Payload to import the new payload into the execution engine. Engine: Fork Choice Updated to make the new payload canonical, now with a change of both safe and unsafe fields to refer to the payload, and no payload attributes. Engine API Error handling: On RPC-type errors the payload attributes processing should be re-attempted in a future step. On payload processing errors the attributes must be dropped, and the forkchoice state must be left unchanged. Eventually the derivation pipeline will produce alternative payload attributes, with or without batches. If the payload attributes only contained deposits, then it is a critical derivation error if these are invalid. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. Processing unsafe payload attributes If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as an \"unsafe\" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the user to see the head of the L2 chain faster than the L1 may confirm the L2 batches. To process unsafe payloads, the payload must: Have a block number higher than the current safe L2 head. The safe L2 head may only be reorged out due to L1 reorgs. Have a parent blockhash that matches the current unsafe L2 head. This prevents the execution engine individually syncing a larger gap in the unsafe L2 chain. This prevents unsafe L2 blocks from reorging other previously validated L2 blocks. This check may change in the future versions to adopt e.g. the L1 snap-sync protocol. The payload is then processed with a sequence of: Bedrock/Canyon/Delta Payloads engine_newPayloadV2: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV2: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Ecotone Payloads engine_newPayloadV3: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV3: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Engine API Error handling: On RPC-type errors the payload processing should be re-attempted in a future step. On payload processing errors the payload must be dropped, and not be marked as canonical. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Engine Queue","id":"157","title":"Engine Queue"},"158":{"body":"It is possible to reset the pipeline, for instance if we detect an L1 reorg (reorganization) . This enables the rollup node to handle L1 chain reorg events. Resetting will recover the pipeline into a state that produces the same outputs as a full L2 derivation process, but starting from an existing L2 chain that is traversed back just enough to reconcile with the current L1 chain. Note that this algorithm covers several important use-cases: Initialize the pipeline without starting from 0, e.g. when the rollup node restarts with an existing engine instance. Recover the pipeline if it becomes inconsistent with the execution engine chain, e.g. when the engine syncs/changes. Recover the pipeline when the L1 chain reorganizes, e.g. a late L1 block is orphaned, or a larger attestation failure. Initialize the pipeline to derive a disputed L2 block with prior L1 and L2 history inside a fault-proof program. Handling these cases also means a node can be configured to eagerly sync L1 data with 0 confirmations, as it can undo the changes if the L1 later does recognize the data as canonical, enabling safe low-latency usage. The Engine Queue is first reset, to determine the L1 and L2 starting points to continue derivation from. After this, the other stages are reset independent of each other. Finding the sync starting point To find the starting point, there are several steps, relative to the head of the chain traversing back: Find the current L2 forkchoice state If no finalized block can be found, start at the Bedrock genesis block. If no safe block can be found, fallback to the finalized block. The unsafe block should always be available and consistent with the above (it may not be in rare engine-corruption recovery cases, this is being reviewed). Find the first L2 block with plausible L1 reference to be the new unsafe starting point, starting from previous unsafe, back to finalized and no further. Plausible iff: the L1 origin of the L2 block is known and canonical, or unknown and has a block-number ahead of L1. Find the first L2 block with an L1 reference older than the sequencing window, to be the new safe starting point, starting at the above plausible unsafe head, back to finalized and no further. If at any point the L1 origin is known but not canonical, the unsafe head is revised to parent of the current. The highest L2 block with known canonical L1 origin is remembered as highest. If at any point the L1 origin in the block is corrupt w.r.t. derivation rules, then error. Corruption includes: Inconsistent L1 origin block number or parent-hash with parent L1 origin Inconsistent L1 sequence number (always changes to 0 for a L1 origin change, or increments by 1 if not) If the L1 origin of the L2 block n is older than the L1 origin of highest by more than a sequence window, and n.sequence_number == 0, then the parent L2 block of n will be the safe starting point. The finalized L2 block persists as the finalized starting point. Find the first L2 block with an L1 reference older than the channel-timeout The L1 origin referenced by this block which we call l2base will be the base for the L2 pipeline derivation: By starting here, the stages can buffer any necessary data, while dropping incomplete derivation outputs until L1 traversal has caught up with the actual L2 safe head. While traversing back the L2 chain, an implementation may sanity-check that the starting point is never set too far back compared to the existing forkchoice state, to avoid an intensive reorg because of misconfiguration. Implementers note: step 1-4 are known as FindL2Heads. Step 5 is currently part of the Engine Queue reset. This may change to isolate the starting-point search from the bare reset logic. Resetting derivation stages L1 Traversal: start at L1 base as first block to be pulled by next stage. L1 Retrieval: empty previous data, and fetch the base L1 data, or defer the fetching work to a later pipeline step. Frame Queue: empty the queue. Channel Bank: empty the channel bank. Channel Reader: reset any batch decoding state. Batch Queue: empty the batch queue, use base as initial L1 point of reference. Payload Attributes Derivation: empty any batch/attributes state. Engine Queue: Initialize L2 forkchoice state with syncing start point state. (finalized/safe/unsafe) Initialize the L1 point of reference of the stage to base. Require a forkchoice update as first task Reset any finality data Where necessary, stages starting at base can initialize their system-config from data encoded in the l2base block. About reorgs Post-Merge Note that post- merge , the depth of reorgs will be bounded by the L1 finality delay (2 L1 beacon epochs, or approximately 13 minutes, unless more than 1/3 of the network consistently disagrees). New L1 blocks may be finalized every L1 beacon epoch (approximately 6.4 minutes), and depending on these finality-signals and batch-inclusion, the derived L2 chain will become irreversible as well. Note that this form of finalization only affects inputs, and nodes can then subjectively say the chain is irreversible, by reproducing the chain from these irreversible inputs and the set protocol rules and parameters. This is however completely unrelated to the outputs posted on L1, which require a form of proof like a fault-proof or zk-proof to finalize. Optimistic-rollup outputs like withdrawals on L1 are only labeled \"finalized\" after passing a week without dispute (fault proof challenge window), a name-collision with the proof-of-stake finalization.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Resetting the Pipeline","id":"158","title":"Resetting the Pipeline"},"159":{"body":"For every L2 block derived from L1 data, we need to build payload attributes , represented by an expanded version of the PayloadAttributesV2 object, which includes additional transactions and noTxPool fields. This process happens during the payloads-attributes queue ran by a verifier node, as well as during block-production ran by a sequencer node (the sequencer may enable the tx-pool usage if the transactions are batch-submitted).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving Payload Attributes","id":"159","title":"Deriving Payload Attributes"},"16":{"body":"Sequencers fill the role of the block producer on an OP Stack chain. Chains may have a single Sequencer or may choose to utilize some consensus protocol that coordinates multiple Sequencers. The OP Stack currently officially only supports a single active Sequencer at any given time. In general, specifications may use the term \"the Sequencer\" as a stand-in for either a single Sequencer or a consensus protocol of multiple Sequencers. The Sequencer: Accepts transactions directly from Users. Observes \"deposit\" transactions generated on Ethereum. Consolidates both transaction streams into ordered L2 blocks. Submits information to L1 that is sufficient to fully reproduce those L2 blocks. Provides real-time access to pending L2 blocks that have not yet been confirmed on L1. The Sequencer serves an important role for the operation of an L2 chain but is not a trusted actor. The Sequencer is generally responsible for improving the user experience by ordering transactions much more quickly and cheaply than would currently be possible if users were to submit all transactions directly to L1.","breadcrumbs":"Background » Sequencers","id":"16","title":"Sequencers"},"160":{"body":"For each L2 block to be created by the sequencer, we start from a sequencer batch matching the target L2 block number. This could potentially be an empty auto-generated batch, if the L1 chain did not include a batch for the target L2 block number. Remember that the batch includes a sequencing epoch number, an L2 timestamp, and a transaction list. This block is part of a sequencing epoch , whose number matches that of an L1 block (its L1 origin ). This L1 block is used to derive L1 attributes and (for the first L2 block in the epoch) user deposits. Therefore, a PayloadAttributesV2 object must include the following transactions: one or more deposited transactions , of two kinds: a single L1 attributes deposited transaction , derived from the L1 origin. for the first L2 block in the epoch, zero or more user-deposited transactions , derived from the receipts of the L1 origin. zero or more network upgrade automation transactions : special transactions to perform network upgrades. zero or more sequenced transactions : regular transactions signed by L2 users, included in the sequencer batch. Transactions must appear in this order in the payload attributes. The L1 attributes are read from the L1 block header, while deposits are read from the L1 block's receipts . Refer to the deposit contract specification for details on how deposits are encoded as log entries.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving the Transaction List","id":"160","title":"Deriving the Transaction List"},"161":{"body":"Some network upgrades require automated contract changes or deployments at specific blocks. To automate these, without adding persistent changes to the execution-layer, special transactions may be inserted as part of the derivation process. Ecotone The Ecotone hardfork activation block contains the following transactions, in this order: L1 Attributes Transaction, using the pre-Ecotone setL1BlockValues User deposits from L1 Network Upgrade Transactions L1Block deployment GasPriceOracle deployment Update L1Block Proxy ERC-1967 Implementation Slot Update GasPriceOracle Proxy ERC-1967 Implementation Slot GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) To not modify or interrupt the system behavior around gas computation, this block will not include any sequenced transactions by setting noTxPool: true. L1Block Deployment The L1Block contract is upgraded to process the new Ecotone L1-data-fee parameters and L1 blob base-fee. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000000 to: null mint: 0 value: 0 gasLimit: 375,000 data: 0x60806040523480156100105... ( full bytecode ) sourceHash: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Deployment\" This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000000\nComputed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Deployment\"))\n# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json This transaction MUST deploy a contract with the following code hash 0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd. GasPriceOracle Deployment The GasPriceOracle contract is upgraded to support the new Ecotone L1-data-fee parameters. Post fork this contract will use the blob base fee to compute the gas price for L1-data-fee transactions. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000001 to: null, mint: 0 value: 0 gasLimit: 1,000,000 data: 0x60806040523480156100... ( full bytecode ) sourceHash: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Deployment\" This results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000001\nComputed Address: 0xb528D11cC114E026F138fE568744c6D45ce6Da7A Verify sourceHash: ❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Deployment\"))\n# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json This transaction MUST deploy a contract with the following code hash 0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5. L1Block Proxy Update This transaction updates the L1Block Proxy ERC-1967 implementation slot to point to the new L1Block deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x4200000000000000000000000000000000000015 (L1Block Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff sourceHash: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)\n0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Proxy Update\"))\n# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc GasPriceOracle Proxy Update This transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a sourceHash: 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: Gas Price Oracle Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)\n0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Proxy Update\"))\n# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a GasPriceOracle Enable Ecotone This transaction informs the GasPriceOracle to start using the Ecotone gas calculation formula. A deposit transaction is derived with the following attributes: from: 0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 (Depositer Account) to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 80,000 data: 0x22b90ab3 sourceHash: 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Set Ecotone\" Verify data: cast sig \"setEcotone()\"\n0x22b90ab3 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Set Ecotone\"))\n# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93 Beacon block roots contract deployment (EIP-4788) EIP-4788 introduces a \"Beacon block roots\" contract, that processes and exposes the beacon-block-root values. at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02. For deployment, EIP-4788 defines a pre- EIP-155 legacy transaction, sent from a key that is derived such that the transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code. However, this type of transaction requires manual deployment and gas-payments. And since the processing is an integral part of the chain processing, and has to be repeated for every OP-Stack chain, the deployment is approached differently here. Some chains may already have a user-submitted instance of the EIP-4788 transaction. This is cryptographically guaranteed to be correct, but may result in the upgrade transaction deploying a second contract, with the next nonce. The result of this deployment can be ignored. A Deposit transaction is derived with the following attributes: from: 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875, as specified in the EIP. to: null mint: 0 value: 0 gasLimit: 0x3d090, as specified in the EIP. isCreation: true data: 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500 isSystemTx: false, as per the Regolith upgrade, even the system-generated transactions spend gas. sourceHash: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c, computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: beacon block roots contract deployment\" The contract address upon deployment is computed as rlp([sender, nonce]), which will equal: BEACON_ROOTS_ADDRESS if deployed a different address (0xE3aE1Ae551eeEda337c0BfF6C4c7cbA98dce353B) if nonce = 1: when a user already submitted the EIP transaction before the upgrade. Verify BEACON_ROOTS_ADDRESS: cast compute-address --nonce=0 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875\n# Computed Address: 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: beacon block roots contract deployment\"))\n# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Network upgrade automation transactions","id":"161","title":"Network upgrade automation transactions"},"162":{"body":"After deriving the transactions list, the rollup node constructs a PayloadAttributesV2 as follows: timestamp is set to the batch's timestamp. random is set to the prev_randao L1 block attribute. suggestedFeeRecipient is set to the Sequencer Fee Vault address. See Fee Vaults specification. transactions is the array of the derived transactions: deposited transactions and sequenced transactions, all encoded with EIP-2718 . noTxPool is set to true, to use the exact above transactions list when constructing the block. gasLimit is set to the current gasLimit value in the system configuration of this payload. withdrawals is set to nil prior to Canyon and an empty array after Canyon","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Building Individual Payload Attributes","id":"162","title":"Building Individual Payload Attributes"},"163":{"body":"Table of Contents Overview","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Batch Submitter","id":"163","title":"Batch Submitter"},"164":{"body":"The batch submitter, also referred to as the batcher, is the entity submitting the L2 sequencer data to L1, to make it available for verifiers. The format of the data transactions is defined in the derivation spec : the data is constructed from L2 blocks in the reverse order as it is derived from data into L2 blocks. The timing, operation and transaction signing is implementation-specific: any data can be submitted at any time, but only the data that matches the derivation spec rules will be valid from the verifier perspective. The most minimal batcher implementation can be defined as a loop of the following operations: See if the unsafe L2 block number is past the safe block number: unsafe data needs to be submitted. Iterate over all unsafe L2 blocks, skip any that were previously submitted. Open a channel, buffer all the L2 block data to be submitted, while applying the encoding and compression as defined in the derivation spec . Pull frames from the channel to fill data transactions with, until the channel is empty. Submit the data transactions to L1 The L2 view of safe/unsafe does not instantly update after data is submitted, nor when it gets confirmed on L1, so special care may have to be taken to not duplicate data submissions.","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Overview","id":"164","title":"Overview"},"165":{"body":"Table of Contents Overview Pre-image Oracle Pre-image key types Type 0: Zero key Type 1: Local key Type 2: Global keccak256 key Type 3: Global generic key Type 4: Global SHA2-256 key Type 5: Global EIP-4844 Point-evaluation key Type 6: Global Precompile key Type 7-128: reserved range Type 129-255: application usage Bootstrapping Hinting Pre-image communication Fault Proof Program Prologue Main content Epilogue Pre-image hinting routes l1-block-header l1-transactions l1-receipts l1-precompile l2-block-header l2-transactions l2-code l2-state-node l2-output Precompile Accelerators Fault Proof VM Fault Proof Interactive Dispute Game","breadcrumbs":"OP Stack Protocol » Fault Proof » Fault Proof","id":"165","title":"Fault Proof"},"166":{"body":"A fault proof, also known as fraud proof or interactive game, consists of 3 components: Program : given a commitment to all rollup inputs (L1 data) and the dispute, verify the dispute statelessly. VM : given a stateless program and its inputs, trace any instruction step, and prove it on L1. Interactive Dispute Game : bisect a dispute down to a single instruction, and resolve the base-case using the VM. Each of these 3 components may have different implementations, which can be combined into different proof stacks, and contribute to proof diversity when resolving a dispute. \"Stateless execution\" of the program, and its individual instructions, refers to reproducing the exact same computation by authenticating the inputs with a Pre-image Oracle . Diagram of Program and VM architecture","breadcrumbs":"OP Stack Protocol » Fault Proof » Overview","id":"166","title":"Overview"},"167":{"body":"The pre-image oracle is the only form of communication between the Program (in the Client role) and the VM (in the Server role). The program uses the pre-image oracle to query any input data that is understood to be available to the user: The initial inputs to bootstrap the program. See Bootstrapping . External data not already part of the program code. See Pre-image hinting routes . The communication happens over a simple request-response wire protocol, see Pre-image communication .","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image Oracle","id":"167","title":"Pre-image Oracle"},"168":{"body":"Pre-images are identified by a bytes32 type-prefixed key: The first byte identifies the type of request. The remaining 31 bytes identify the pre-image key. Type 0: Zero key The zero prefix is illegal. This ensures all pre-image keys are non-zero, enabling storage lookup optimizations and avoiding easy mistakes with invalid zeroed keys in the EVM. Type 1: Local key Information specific to the dispute: the remainder of the key may be an index, a string, a hash, etc. Only the contract(s) managing this dispute instance may serve the value for this key: it is localized and context-dependent. This type of key is used for program bootstrapping, to identify the initial input arguments by index or name. Type 2: Global keccak256 key This type of key uses a global pre-image store contract, and is fully context-independent and permissionless. I.e. every key must have a single unique value, regardless of chain history or time. Using a global store reduces duplicate pre-image registration work, and avoids unnecessary contract redeployments per dispute. This global store contract should be non-upgradeable. Since keccak256 is a safe 32-byte hash input, the first byte is overwritten with a 2 to derive the key, while keeping the rest of the key \"readable\" (matching the original hash). Type 3: Global generic key Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments. This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:], where: x is a bytes32, which can be a hash of an arbitrary-length type of cryptographically secure commitment. sender is a bytes32 identifying the pre-image inserter address (left-padded to 32 bytes) This global store contract should be non-upgradeable. The global contract is permissionless: users can standardize around external contracts that verify pre-images (i.e. a specific sender will always be trusted for a specific kind of pre-image). The external contract verifies the pre-image before inserting it into the global store for usage by all fault proof VMs without requiring the VM or global store contract to be changed. Users may standardize around upgradeable external pre-image contracts, in case the implementation of the verification of the pre-image is expected to change. The store update function is update(x bytes32, offset uint64, span uint8, value bytes32): x is the bytes32 x that the pre-image key is computed with. Only part of the pre-image, starting at offset, and up to (incl.) 32 bytes span can be inserted at a time. Pre-images may have an undefined length (e.g. a stream), we only need to know how many bytes of value are usable. The key and offset will be hashed together to uniquely store the value and span, for later pre-image serving. This enables fault proof programs to adopt any new pre-image schemes without VM update or contract redeployment. It is up to the user to index the special pre-image values by this key scheme, as there is no way to revert it to the original commitment without knowing said commitment or value. Type 4: Global SHA2-256 key A SHA-256 pre-image. Key: the SHA-256 hash, with the first byte overwritten with the type byte: 4 ++ sha256(data)[1:]. Type 5: Global EIP-4844 Point-evaluation key An EIP-4844 point-evaluation. In an EIP-4844 blob, 4096 field elements represent the blob data. It verifies p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof. The value y is the pre-image. The value z is part of the key; the index of the point within the blob. The commitment is part of the key. Each element is proven with a point-evaluation. Key: 5 ++ keccak256(commitment ++ z)[1:], where: 5 is the type byte ++ is concatenation commitment is a bytes48, representing the KZG commitment. z is a big-endian uint256 Type 6: Global Precompile key A precompile result. It maps directly to precompiles on Ethereum. This preimage key can be used to avoid running expensive precompile operations in the program. Key: 6 ++ keccak256(precompile ++ input)[1:], where: 6 is the type byte ++ is concatenation precompile is the 20-byte address of the precompile contract input is the input to the precompile contract The result is identical to that of a call to the precompile contract, prefixed with a revert indicator: reverted ++ precompile_result. reverted is a 1-byte indicator with a 0 value if the precompile reverts for the given input, otherwise it's 1. Type 7-128: reserved range Range start and end both inclusive. This range of key types is reserved for future usage by the core protocol. E.g. version changes, contract migrations, chain-data, additional core features, etc. 128 specifically (1000 0000 in binary) is reserved for key-type length-extension (reducing the content part to 30 or less key bytes), if the need arises. Type 129-255: application usage This range of key types may be used by forks or customized versions of the fault proof protocol.","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image key types","id":"168","title":"Pre-image key types"},"169":{"body":"Initial inputs are deterministic, but not necessarily singular or global: there may be multiple different disputes at the same time, each with its own disputed claims and L1 context. To bootstrap, the program requests the initial inputs from the VM, using pre-image key type 1. The VM is aware of the external context, and maps requested pre-image keys based on their type, i.e. a local lookup for type 1, or global one for 2, and optionally support other key-types.","breadcrumbs":"OP Stack Protocol » Fault Proof » Bootstrapping","id":"169","title":"Bootstrapping"},"17":{"body":"Verifiers download and execute the L2 state transition function independently of the Sequencer. Verifiers help to maintain the integrity of the network and serve blockchain data to Users. Verifiers generally: Download rollup data from L1 and the Sequencer. Use rollup data to execute the L2 state transition function. Serve rollup data and computed L2 state information to Users. Verifiers can also act as Proposers and/or Challengers who: Submit assertions about the state of the L2 to a smart contract on L1. Validate assertions made by other participants. Dispute invalid assertions made by other participants.","breadcrumbs":"Background » Verifiers","id":"17","title":"Verifiers"},"170":{"body":"There is one more form of optional communication between client and server: pre-image hinting. Hinting is optional, and is a no-op in a L1 VM implementation. The hint itself comes at very low cost onchain: the hint can be a single write sys-call, which is instant as the memory to write as hint does not actually need to be loaded as part of the onchain proof. Hinting allows the program, when generating a proof offchain, to instruct the VM what data it is interested in. The VM can choose to execute the requested hint at any time: either locally (for standard requests), or in a modular form by redirecting the hint to tooling that may come with the VM program. Hints do not have to be executed directly: they may first just be logged to show the intents of the program, and the latest hint may be buffered for lazy execution, or dropped entirely when in read-only mode (like onchain). When the pre-image oracle serves a request, and the request cannot be served from an existing collection of pre-images (e.g. a local pre-image cache) then the VM can execute the hint to retrieve the missing pre-image(s). It is the responsibility of the program to provide sufficient hinting for every pre-image request. Some hints may have to be repeated: the VM only has to execute the last hint when handling a missing pre-image. Note that hints may produce multiple pre-images: e.g. a hint for an ethereum block with transaction list may prepare pre-images for the header, each of the transactions, and the intermediate merkle-nodes that form the transactions-list Merkle Patricia Trie. Hinting is implemented with a request-acknowledgement wire-protocol over a blocking two-way stream: := := := big-endian uint32 # length of \n := byte sequence\n := 1-byte zero value The ack informs the client that the hint has been processed. Servers may respond to hints and pre-image (see below) requests asynchronously as they are on separate streams. To avoid requesting pre-images that are not yet fetched, clients should request the pre-image only after it has observed the hint acknowledgement.","breadcrumbs":"OP Stack Protocol » Fault Proof » Hinting","id":"170","title":"Hinting"},"171":{"body":"Pre-images are communicated with a minimal wire-protocol over a blocking two-way stream. This protocol can be implemented with blocking read/write syscalls. :=
denominator
u32 (big-endian)
[0, 4)
elasticity
[4, 8)
This type is made available in the payload attributes to allow the block builder to dynamically control the EIP-1559 parameters of the chain. As described in the derivation - AttributesBuilder section, the derivation pipeline must populate this field from the SystemConfig during payload building, similar to how it must reference the SystemConfig for the gasLimit field.
gasLimit
Upon Holocene activation, the L2 block header's nonce field will consist of the 8-byte eip1559Params value.
Prior to Holocene activation, the L2 block header's nonce field is valid iff it is equal to u64(0).
u64(0)
After Holocene activation, The L2 block header's nonce field is valid iff it is non-zero.
The encoding of the eip1559Params value is described in eip1559Params encoding.
By chosing to put the eip1559Params in the PayloadAttributes rather than in the L1 block info transaction, the EIP-1559 parameters for the chain are not available within history. This would place a burden on performing historical execution, as L1 would have to be consulted for fetching the values from the SystemConfig contract. @@ -9153,251 +9106,27 @@
PayloadAttributes
setHolocene
setConfig
baseFeeVaultConfig
sequencerFeeVaultConfig
l1FeeVaultConfig
l1CrossDomainMessenger
l1StandardBridge
l1ERC721Bridge
remoteChainId
config
This upgrade enables a deterministic L2 genesis state by moving all network -specific configuration out of the initial L2 genesis state. All network specific -configuration is sourced from deposit transactions during the initialization -of the SystemConfig.
ConfigType
uint8
WithdrawalNetwork
uint8(0)
uint8(1)
0
1
RECIPIENT
address
FeeVault
MIN_WITHDRAWAL_AMOUNT
uint256
bytes32
bytes32((WithdrawalNetwork << 248) || uint256(uint88(MIN_WITHDRAWAL_AMOUNT)) || uint256(uint160(RECIPIENT)))
BASE_FEE_VAULT_CONFIG
bytes32(uint256(keccak256("opstack.basefeevaultconfig")) - 1)
BaseFeeVault
L1_FEE_VAULT_CONFIG
bytes32(uint256(keccak256("opstack.l1feevaultconfig")) - 1)
L1FeeVault
SEQUENCER_FEE_VAULT_CONFIG
bytes32(uint256(keccak256("opstack.sequencerfeevaultconfig")) - 1)
SequencerFeeVault
L1_CROSS_DOMAIN_MESSENGER_ADDRESS
bytes32(uint256(keccak256("opstack.l1crossdomainmessengeraddress")) - 1)
abi.encode(address(L1CrossDomainMessengerProxy))
L1_ERC_721_BRIDGE_ADDRESS
bytes32(uint256(keccak256("opstack.l1erc721bridgeaddress")) - 1)
abi.encode(address(L1ERC721BridgeProxy))
L1_STANDARD_BRIDGE_ADDRESS
bytes32(uint256(keccak256("opstack.l1standardbridgeaddress")) - 1)
abi.encode(address(L1StandardBridgeProxy))
REMOTE_CHAIN_ID
bytes32(uint256(keccak256("opstack.remotechainid")) - 1)
All network specific configuration is moved to a single contract, the L1Block predeploy. -All predeploys make calls to the L1Block contract to fetch network specific configuration -rather than reading it from local state.
L1Block
graph LR - subgraph L1 - SystemConfig -- "setConfig(uint8,bytes)" --> OptimismPortal - end - subgraph L2 - L1Block - BaseFeeVault -- "baseFeeVaultConfig()(address,uint256,uint8)" --> L1Block - SequencerFeeVault -- "sequencerFeeVaultConfig()(address,uint256,uint8)" --> L1Block - L1FeeVault -- "l1FeeVaultConfig()(address,uint256,uint8)" --> L1Block - L2CrossDomainMessenger -- "l1CrossDomainMessenger()(address)" --> L1Block - L2StandardBridge -- "l1StandardBridge()(address)" --> L1Block - L2ERC721Bridge -- "l1ERC721Bridge()(address)" --> L1Block - OptimismMintableERC721Factory -- "remoteChainId()(uint256)" --> L1Block - end - OptimismPortal -- "setConfig(uint8,bytes)" --> L1Block -
The following storage slots are defined:
Each slot MUST have a defined ConfigType that authorizes the setting of the storage slot -via a deposit transaction from the DEPOSITOR_ACCOUNT.
DEPOSITOR_ACCOUNT
This function is meant to be called once on the activation block of the holocene network upgrade. -It MUST only be callable by the DEPOSITOR_ACCOUNT once. When it is called, it MUST call -call each getter for the network specific config and set the returndata into storage.
This function MUST only be callable by the DEPOSITOR_ACCOUNT. It modifies the storage directly -of the L1Block contract. It MUST handle all defined ConfigTypes. To ensure a simple ABI, the -bytes value MUST be abi decoded based on the ConfigType.
bytes
function setConfig(ConfigType,bytes) -
Note that ConfigType is an enum which is an alias for a uint8.
This function MUST be called by the BaseFeeVault to fetch network specific configuration.
function baseFeeVaultConfig()(address,uint256,WithdrawalNetwork) -
This function MUST be called by the SequencerFeeVault to fetch network specific configuration.
function sequencerFeeVaultConfig()(address,uint256,WithdrawalNetwork) -
This function MUST be called by the L1FeeVault to fetch network specific configuration.
function l1FeeVaultConfig()(address,uint256,WithdrawalNetwork) -
This function MUST be called by the L2CrossDomainMessenger to fetch the address of the L1CrossDomainMessenger.
L2CrossDomainMessenger
L1CrossDomainMessenger
function l1CrossDomainMessenger()(address) -
This function MUST be called by the L2StandardBridge to fetch the address of the L2CrossDomainMessenger.
L2StandardBridge
function l1StandardBridge()(address) -
This function MUST be called by the L2ERC721Bridge to fetch the address of the L1ERC721Bridge.
L2ERC721Bridge
L1ERC721Bridge
function l1ERC721Bridge()(address) -
This function MUST be called by the OptimismMintableERC721Factory to fetch the chain id of the remote chain. -For an L2, this is the L1 chain id.
OptimismMintableERC721Factory
function remoteChainId()(uint256) -
The following changes apply to each of the BaseFeeVault, the L1FeeVault and the SequencerFeeVault.
The following functions are updated to read from the L1Block contract:
recipient()(address)
withdrawalNetwork()(WithdrawalNetwork)
minWithdrawalAmount()(uint256)
withdraw()
L1Block.baseFeeVaultConfig()
L1Block.sequencerFeeVaultConfig()
L1Block.l1FeeVaultConfig()
A new function is added to fetch the full Fee Vault Config.
function config()(address,uint256,WithdrawalNetwork) -
The following functions are updated to read from the L1Block contract by calling L1Block.l1CrossDomainMessenger():
L1Block.l1CrossDomainMessenger()
otherMessenger()(address)
OTHER_MESSENGER()(address)
The following functions are updated to read from the L1Block contract by calling L1Block.l1ERC721Bridge()
L1Block.l1ERC721Bridge()
otherBridge()(address)
OTHER_BRIDGE()(address)
The following functions are updated to read from the L1Block contract by calling L1Block.l1StandardBridge()
L1Block.l1StandardBridge()
The chain id is no longer read from storage but instead is read from the L1Block contract by calling -L1Block.remoteChainId()
L1Block.remoteChainId()
The predeploy defined by GovernanceToken should be an empty account until it is defined by -a future hardfork.
GovernanceToken
ConfigUpdate
setEIP1559Params
eip1559Elasticity
eip1559Denominator
setBaseFeeVaultConfig
setL1FeeVaultConfig
setSequencerFeeVaultConfig
OptimismPortal
The SystemConfig and OptimismPortal are updated with a new flow for chain -configurability.
The ConfigType enum represents configuration that can be modified.
SET_GAS_PAYING_TOKEN
SET_BASE_FEE_VAULT_CONFIG
SET_L1_FEE_VAULT_CONFIG
uint8(2)
SET_SEQUENCER_FEE_VAULT_CONFIG
uint8(3)
SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESS
uint8(4)
SET_L1_ERC_721_BRIDGE_ADDRESS
uint8(5)
SET_L1_STANDARD_BRIDGE_ADDRESS
uint8(6)
L1StandardBridge
SET_REMOTE_CHAIN_ID
uint8(7)
The SystemConfig is updated to allow for dynamic EIP-1559 parameters.
The following ConfigUpdate event is defined where the CONFIG_VERSION is uint256(0):
CONFIG_VERSION
uint256(0)
emit ConfigUpdate.GAS_LIMIT
emit ConfigUpdate.UNSAFE_BLOCK_SIGNER
emit ConfigUpdate.EIP_1559_PARAMS
setConfig(SET_GAS_PAYING_TOKEN)
setConfig(SET_BASE_FEE_VAULT_CONFIG)
setConfig(SET_L1_FEE_VAULT_CONFIG)
setConfig(SET_SEQUENCER_FEE_VAULT_CONFIG)
setConfig(SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESS)
setConfig(SET_L1_ERC_721_BRIDGE_ADDRESS)
setConfig(SET_L1_STANDARD_BRIDGE_ADDRESS)
setConfig(SET_REMOTE_CHAIN_ID)
These actions MAY only be triggered if there is a diff to the value.
A new SystemConfig UpdateType is introduced that enables the modification of EIP-1559 parameters. This allows for the chain operator to modify the BASE_FEE_MAX_CHANGE_DENOMINATOR and the ELASTICITY_MULTIPLIER.
UpdateType
BASE_FEE_MAX_CHANGE_DENOMINATOR
ELASTICITY_MULTIPLIER
This function MUST only be callable by the chain governor.
e This function returns the currently configured EIP-1559 denominator. function eip1559Denominator()(uint64) -Fee Vault Config -For each FeeVault, there is a setter for its config. The arguments to the setter include -the RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork. -Each of these functions should be public and only callable by the chain governor. -Each function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType. -setBaseFeeVaultConfig -function setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork) - -setL1FeeVaultConfig -function setL1FeeVaultConfig(address,uint256,WithdrawalNetwork) - -setSequencerFeeVaultConfig -function setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork) - -OptimismPortal -The OptimismPortal is updated to emit a special system TransactionDeposited event. -Interface -setConfig -The setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig -is the single source of truth for chain operator ownership. -function setConfig(ConfigType,bytes) - -This function emits a TransactionDeposited event. -event TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData); - -The following fields are included: - -from is the DEPOSITOR_ACCOUNT -to is Predeploys.L1Block -version is uint256(0) -opaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit -is 200_000, isCreation is false and the data is abi.encodeCall(L1Block.setConfig, (_type, _value)) - Governance Token @@ -9670,7 +9341,7 @@ Overview The terms "custom gas token", "gas paying token", "native asset" and "gas paying asset" can all be used interchangeably. Note, Ether is not a custom gas token, but may be used to pay gas. More on this in Configuring the Gas Paying Token. -Constants +Constants ConstantValueDescription ETHER_TOKEN_ADDRESSaddress(0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE)Represents ether for gas paying asset DEPOSITOR_ACCOUNTaddress(0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001)Account with auth permissions on L1Block contract @@ -9766,7 +9437,7 @@ Gas Token Awa L2CrossDomainMessenger OptimismPortal -OptimismPortal +OptimismPortal The OptimismPortal is updated with a new interface specifically for depositing custom tokens. depositERC20Transaction The depositERC20Transaction function is useful for sending custom gas tokens to L2. It is broken out into its @@ -9848,7 +9519,7 @@ Cro The L1CrossDomainMessenger fetches this tuple from the SystemConfig contract. The L2CrossDomainMessenger fetches this tuple from the L1Block contract. -SystemConfig +SystemConfig The SystemConfig is the source of truth for the address of the custom gas token. It does on chain validation, stores information about the token and well as passes the information to L2. initialize @@ -9860,7 +9531,7 @@ initialize symbol MUST be less than or equal to 32 bytes. If the token passes all of these checks, OptimismPortal.setGasPayingToken is called. The implementation of initialize MUST not allow the chain operator to change the address of the custom gas token if it is already set. -L1Block +L1Block The L1Block contract is upgraded with a permissioned function setGasPayingToken that is used to set information about the gas paying token. The DEPOSITOR_ACCOUNT MUST be the only account that can call the setter function. This setter is differentiated from the setL1BlockValues functions because the gas paying @@ -10019,7 +9690,7 @@ Fees blobbasefee. When a custom gas token is used, fees are paid in the custom gas token but the conversion rate to ether is not taken into account as part of the protocol. It is assumed that the fees will be configured by the chain operator such that the revenue earned in custom gas token can be swapped into ether to pay for posting the data to L1. -Security Considerations +Security Considerations OptimismPortal Token Allowance The OptimismPortal makes calls on behalf of users. It is therefore unsafe to be able to call the address of the custom gas token itself from the OptimismPortal because it would be a simple way to approve an attacker's @@ -10287,7 +9958,7 @@ Safet that an L2 block is derived from becomes finalized, the L2 block can be marked as finalized. The engine queue will maintain a longer buffer of L2 blocks waiting for the DA window to expire and the L1 block with the commitment to be finalized in order to signal finality. -Security Considerations +Security Considerations The Data Availability Challenge contract mitigates DoS vulnerability with a payable bond requirement making challenging the availability of a commitment at least as expensive as submitting the data onchain to resolve the challenge. @@ -10387,7 +10058,7 @@ Security Considerations +Security Considerations Layer 1 as Part of the Dependency Set The layer one MAY be part of the dependency set if the fault proof implementation is set up to support it. It is known that it is possible but it is not known if this is going to be @@ -10603,7 +10274,7 @@ Boundin Every block cannot depend on expired messages, as per the Message expiry invariant. The verifier is responsible for filtering out non-canonical parts of the graph. -Security Considerations +Security Considerations Cyclic dependencies If there is a cycle in the dependency set, chains MUST still be able to promote unsafe blocks to safe blocks. A cycle in the dependency set happens anytime that two chains are in each other's @@ -11126,7 +10797,7 @@ Overview The Beacon Contract implements the interface defined in EIP-1967. The implementation address gets deduced similarly to the GasPriceOracle address in Ecotone and Fjord updates. -L1Block +L1Block ConstantValue Address0x4200000000000000000000000000000000000015 DEPOSITOR_ACCOUNT0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 @@ -11253,7 +10924,7 @@ event StandardL2TokenCreated(address indexed remoteToken, address indexed localToken); -L2StandardBridge +L2StandardBridge ConstantValue Address0x4200000000000000000000000000000000000010 @@ -11436,7 +11107,7 @@ Invariants -Security Considerations +Security Considerations TODO Sequencer @@ -11561,7 +11232,7 @@ Sponsorship If a user does not have ether to pay for the gas of an executing message, application layer sponsorship solutions can be created. It is possible to create an MEV incentive by paying tx.origin in the executing message. This can be done by wrapping the L2ToL2CrossDomainMessenger with a pair of relaying contracts. -Security Considerations +Security Considerations Cross Chain Message Latency The latency at which a cross chain message is relayed from the moment at which it was initiated is bottlenecked by the security of the preconfirmations. An initiating transaction and a executing transaction MAY have the same timestamp, @@ -11699,7 +11370,7 @@ Honest Verifi follows. The main difference is that the validity of included executing messages is verified instead of verifying possible executing messages before inclusion. -Security Considerations +Security Considerations Forced Inclusion of Cross Chain Messages The design is particular to not introduce any sort of "forced inclusion" between L2s. This design space introduces risky synchrony assumptions and forces the introduction of a message queue to prevent denial of service attacks where @@ -11739,7 +11410,7 @@ P2P Networking< sets of executing messages to nodes of remote chains so that they know exactly what initiating messages to look for. An optimization on this would involve working with commitments to this data so that less data is sent around via p2p. -Security Considerations +Security Considerations TODO Fault Proof @@ -11761,7 +11432,7 @@ No changes to the dispute game bisection are required. The only changes required are to the fault proof program itself. The insight is that the fault proof program can be a superset of the state transition function. -Security Considerations +Security Considerations TODO Interop Network Upgrade @@ -11839,7 +11510,7 @@ L1 Attributes Deposited Transaction Calldata. -Security Considerations +Security Considerations TODO Token Bridging @@ -11899,7 +11570,7 @@ Properties Notice that ERC20s that do not implement the standard can still be fungible using interop message passing using a custom bridge or implementing sendERC20 and relayERC20 on their own contracts. -Interface +Interface Implementations of the SuperchainERC20 standard will need to implement two external functions and two events: __superchainMint Mints _amount of token to address _account. It should only be callable by the SuperchainERC20Bridge @@ -12098,7 +11769,7 @@ Constants +Constants NameValue SuperchainWETH Address0x4200000000000000000000000000000000000024 ETHLiquidity Address0x4200000000000000000000000000000000000025 @@ -12266,7 +11937,7 @@ Security Considerations +Security Considerations Gas Considerations There must be sufficient gas available in the block to destroy deposit context. There's no guarantee on the minimum gas available for the second L1 attributes transaction as the block @@ -12330,7 +12001,7 @@ Security Considerations +Security Considerations Mempool Denial of Service Since the validation of the executing message relies on a remote RPC request, this introduces a denial of service attack vector. The cost of network access is magnitudes larger than in memory validity checks. @@ -12378,8 +12049,8 @@ OP Deployment The OP Contracts Manager is a proxied contract deployed at 0xTODO. It can be deployed as follows: TODO. -Interface -Version 1.0.0 of the OP Contracts Manager deploys the [op-contracts/v1.6.0] +Interface +Version 1.0.0 of the OP Contracts Manager deploys the op-contracts/v1.6.0 contracts release. Proxy.sol The OP Contracts Manager is a proxied contract using the standard Proxy.sol contract that lives in @@ -12478,7 +12149,7 @@ Con -Security Considerations +Security Considerations Chain ID Source of Truth One of the implicit restrictions on chain ID is that deploy can only be called once per chain ID, because contract addresses are a function of chain ID. However, diff --git a/protocol/batcher.html b/protocol/batcher.html index 3b2dd42f6..b43477961 100644 --- a/protocol/batcher.html +++ b/protocol/batcher.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/bridges.html b/protocol/bridges.html index 82d8153b0..78ccebfed 100644 --- a/protocol/bridges.html +++ b/protocol/bridges.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/canyon/overview.html b/protocol/canyon/overview.html index 6676f930a..60f52a8c2 100644 --- a/protocol/canyon/overview.html +++ b/protocol/canyon/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/configurability.html b/protocol/configurability.html index 79b184b12..8cf628d3c 100644 --- a/protocol/configurability.html +++ b/protocol/configurability.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/delta/overview.html b/protocol/delta/overview.html index a3601d0d5..359a3d161 100644 --- a/protocol/delta/overview.html +++ b/protocol/delta/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/delta/span-batches.html b/protocol/delta/span-batches.html index 3232dddcf..b9de7318b 100644 --- a/protocol/delta/span-batches.html +++ b/protocol/delta/span-batches.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/deposits.html b/protocol/deposits.html index 2e8b7b28a..9edf1b72d 100644 --- a/protocol/deposits.html +++ b/protocol/deposits.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/derivation.html b/protocol/derivation.html index f67e22c5e..b84e7f620 100644 --- a/protocol/derivation.html +++ b/protocol/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/derivation.html b/protocol/ecotone/derivation.html index 69f48b18d..48edf5eae 100644 --- a/protocol/ecotone/derivation.html +++ b/protocol/ecotone/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/l1-attributes.html b/protocol/ecotone/l1-attributes.html index 94c9a9abb..fdba52917 100644 --- a/protocol/ecotone/l1-attributes.html +++ b/protocol/ecotone/l1-attributes.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/overview.html b/protocol/ecotone/overview.html index ffb372c15..d95d00c2b 100644 --- a/protocol/ecotone/overview.html +++ b/protocol/ecotone/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/exec-engine.html b/protocol/exec-engine.html index a994871cc..115393699 100644 --- a/protocol/exec-engine.html +++ b/protocol/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/derivation.html b/protocol/fjord/derivation.html index 344bdbaf3..0a1ae0b01 100644 --- a/protocol/fjord/derivation.html +++ b/protocol/fjord/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/exec-engine.html b/protocol/fjord/exec-engine.html index 01d2281fd..69cb1bc77 100644 --- a/protocol/fjord/exec-engine.html +++ b/protocol/fjord/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/overview.html b/protocol/fjord/overview.html index 783db2fbb..30f1c440c 100644 --- a/protocol/fjord/overview.html +++ b/protocol/fjord/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/predeploys.html b/protocol/fjord/predeploys.html index bae67eae6..d46e6398f 100644 --- a/protocol/fjord/predeploys.html +++ b/protocol/fjord/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/derivation.html b/protocol/granite/derivation.html index e9d88dbae..e19cba517 100644 --- a/protocol/granite/derivation.html +++ b/protocol/granite/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/exec-engine.html b/protocol/granite/exec-engine.html index 8c0f1e46d..684d3fb06 100644 --- a/protocol/granite/exec-engine.html +++ b/protocol/granite/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/overview.html b/protocol/granite/overview.html index 7b5492827..bb2905a4a 100644 --- a/protocol/granite/overview.html +++ b/protocol/granite/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/guaranteed-gas-market.html b/protocol/guaranteed-gas-market.html index c42c12354..863931f80 100644 --- a/protocol/guaranteed-gas-market.html +++ b/protocol/guaranteed-gas-market.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/holocene/derivation.html b/protocol/holocene/derivation.html index f1eea3faf..c38652a86 100644 --- a/protocol/holocene/derivation.html +++ b/protocol/holocene/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/holocene/exec-engine.html b/protocol/holocene/exec-engine.html index d44a82f56..4253e4082 100644 --- a/protocol/holocene/exec-engine.html +++ b/protocol/holocene/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -194,81 +194,36 @@ L2 Ex Table of Contents +Overview Timestamp Activation -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters -Header Validity Rules -Header Withdrawals Root - -Rationale -Forwards Compatibility Considerations -Client Implementation Considerations - - - - Extended PayloadAttributesV3 eip1559Params encoding -Execution -Rationale +Execution +Rationale eip1559Params in Header -Header Validity Rules +Header Validity Rules Encoding -Rationale +Rationale + + +Overview +The EIP-1559 parameters are encoded in the block header's nonce field and can be +configured dynamically through the SystemConfig. Timestamp Activation Holocene, like other network upgrades, is activated at a timestamp. Changes to the L2 Block execution rules are applied when the L2 Timestamp >= activation time. -L2ToL1MessagePasser Storage Root in Header -After Holocene's activation, the L2 block header's withdrawalsRoot field will consist of the 32-byte -L2ToL1MessagePasser account storage root after the block has been executed, and after the -insertions and deletions have been applied to the trie. In other words, the storage root should be the same root -that is returned by eth_getProof at the given block number. -Header Validity Rules -Prior to holocene activation, the L2 block header's withdrawalsRoot field must be: - -nil if Canyon has not been activated. -keccak256(rlp(empty_string_code)) if Canyon has been activated. - -After Holocene activation, an L2 block header's withdrawalsRoot field is valid iff: - -It is exactly 32 bytes in length. -The L2ToL1MessagePasser account storage root, as committed to in the storageRoot within the block -header, is equal to the header's withdrawalsRoot field. - -Header Withdrawals Root -Byte offsetDescription -[0, 32)L2ToL1MessagePasser account storage root - - -Rationale -Currently, to generate L2 output roots for historical blocks, an archival node is required. This directly -places a burden on users of the system in a post-fault-proofs world, where: - -A proposer must have an archive node to propose an output root at the safe head. -A user that is proving their withdrawal must have an archive node to verify that the output root they are proving -their withdrawal against is indeed valid and included within the safe chain. - -Placing the L2ToL1MessagePasser account storage root in the withdrawalsRoot field alleviates this burden -for users and protocol participants alike, allowing them to propose and verify other proposals with lower operating costs. -Forwards Compatibility Considerations -As it stands, the withdrawalsRoot field is unused within the OP Stack's header consensus format, and will never be -used for other reasons that are currently planned. Setting this value to the account storage root of the withdrawal -directly fits with the OP Stack, and makes use of the existing field in the L1 header consensus format. -Client Implementation Considerations -Varous EL clients store historical state of accounts differently. If, as a contrived case, an OP Stack chain did not have -an outbound withdrawal for a long period of time, the node may not have access to the account storage root of the -L2ToL1MessagePasser. In this case, the client would be unable to keep consensus. However, most modern -clients are able to at the very least reconstruct the account storage root at a given block on the fly if it does not -directly store this information. -Extended PayloadAttributesV3 +Dynamic EIP-1559 Parameters +Extended PayloadAttributesV3 The PayloadAttributesV3 type is extended to: PayloadAttributesV3: { @@ -283,7 +238,7 @@ eip1559Params encoding +eip1559Params encoding NameTypeByte Offset denominatoru32 (big-endian)[0, 4) elasticityu32 (big-endian)[4, 8) @@ -303,19 +258,19 @@ Execution -Rationale +Rationale This type is made available in the payload attributes to allow the block builder to dynamically control the EIP-1559 parameters of the chain. As described in the derivation - AttributesBuilder section, the derivation pipeline must populate this field from the SystemConfig during payload building, similar to how it must reference the SystemConfig for the gasLimit field. -eip1559Params in Header +eip1559Params in Header Upon Holocene activation, the L2 block header's nonce field will consist of the 8-byte eip1559Params value. -Header Validity Rules +Header Validity Rules Prior to Holocene activation, the L2 block header's nonce field is valid iff it is equal to u64(0). After Holocene activation, The L2 block header's nonce field is valid iff it is non-zero. -Encoding +Encoding The encoding of the eip1559Params value is described in eip1559Params encoding. -Rationale +Rationale By chosing to put the eip1559Params in the PayloadAttributes rather than in the L1 block info transaction, the EIP-1559 parameters for the chain are not available within history. This would place a burden on performing historical execution, as L1 would have to be consulted for fetching the values from the SystemConfig contract. diff --git a/protocol/holocene/overview.html b/protocol/holocene/overview.html index 0ce159035..1714698a1 100644 --- a/protocol/holocene/overview.html +++ b/protocol/holocene/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -199,10 +199,9 @@ Smart Contracts -This document is not finalized and should be considered experimental. Execution Layer -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters Consensus Layer @@ -210,8 +209,7 @@ Consensus Lay Smart Contracts -Predeploys -Configurability +System Config diff --git a/protocol/holocene/predeploys.html b/protocol/holocene/predeploys.html index 3c4f9c31d..3c6067ec3 100644 --- a/protocol/holocene/predeploys.html +++ b/protocol/holocene/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -189,209 +189,7 @@ OP Stack Specification -Overview - - -Table of Contents - -Constants -Predeploys - -L1Block - -Storage -Interface - -setHolocene -setConfig -baseFeeVaultConfig -sequencerFeeVaultConfig -l1FeeVaultConfig -l1CrossDomainMessenger -l1StandardBridge -l1ERC721Bridge -remoteChainId - - - - -FeeVault - -Interface - -config - - - - -L2CrossDomainMessenger - -Interface - - -L2ERC721Bridge - -Interface - - -L2StandardBridge - -Interface - - -OptimismMintableERC721Factory - - -Security Considerations - -GovernanceToken - - - - -This upgrade enables a deterministic L2 genesis state by moving all network -specific configuration out of the initial L2 genesis state. All network specific -configuration is sourced from deposit transactions during the initialization -of the SystemConfig. -Constants -NameValueDefinition -ConfigTypeuint8An enum representing the type of config being set -WithdrawalNetworkuint8(0) or uint8(1)0 means withdraw to L1, 1 means withdraw to L2 -RECIPIENTaddressThe account that will receive funds sent out of the FeeVault -MIN_WITHDRAWAL_AMOUNTuint256The minimum amount of native asset held in the FeeVault before withdrawal is authorized -Fee Vault Configbytes32bytes32((WithdrawalNetwork << 248) || uint256(uint88(MIN_WITHDRAWAL_AMOUNT)) || uint256(uint160(RECIPIENT))) -BASE_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.basefeevaultconfig")) - 1)The Fee Vault Config for the BaseFeeVault -L1_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.l1feevaultconfig")) - 1)The Fee Vault Config for the L1FeeVault -SEQUENCER_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.sequencerfeevaultconfig")) - 1)The Fee Vault Config for the SequencerFeeVault -L1_CROSS_DOMAIN_MESSENGER_ADDRESSbytes32(uint256(keccak256("opstack.l1crossdomainmessengeraddress")) - 1)abi.encode(address(L1CrossDomainMessengerProxy)) -L1_ERC_721_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1erc721bridgeaddress")) - 1)abi.encode(address(L1ERC721BridgeProxy)) -L1_STANDARD_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1standardbridgeaddress")) - 1)abi.encode(address(L1StandardBridgeProxy)) -REMOTE_CHAIN_IDbytes32(uint256(keccak256("opstack.remotechainid")) - 1)Chain ID of the remote chain - - -Predeploys -All network specific configuration is moved to a single contract, the L1Block predeploy. -All predeploys make calls to the L1Block contract to fetch network specific configuration -rather than reading it from local state. -graph LR - subgraph L1 - SystemConfig -- "setConfig(uint8,bytes)" --> OptimismPortal - end - subgraph L2 - L1Block - BaseFeeVault -- "baseFeeVaultConfig()(address,uint256,uint8)" --> L1Block - SequencerFeeVault -- "sequencerFeeVaultConfig()(address,uint256,uint8)" --> L1Block - L1FeeVault -- "l1FeeVaultConfig()(address,uint256,uint8)" --> L1Block - L2CrossDomainMessenger -- "l1CrossDomainMessenger()(address)" --> L1Block - L2StandardBridge -- "l1StandardBridge()(address)" --> L1Block - L2ERC721Bridge -- "l1ERC721Bridge()(address)" --> L1Block - OptimismMintableERC721Factory -- "remoteChainId()(uint256)" --> L1Block - end - OptimismPortal -- "setConfig(uint8,bytes)" --> L1Block - -L1Block -Storage -The following storage slots are defined: - -BASE_FEE_VAULT_CONFIG -L1_FEE_VAULT_CONFIG -SEQUENCER_FEE_VAULT_CONFIG -L1_CROSS_DOMAIN_MESSENGER_ADDRESS -L1_ERC_721_BRIDGE_ADDRESS -L1_STANDARD_BRIDGE_ADDRESS -REMOTE_CHAIN_ID - -Each slot MUST have a defined ConfigType that authorizes the setting of the storage slot -via a deposit transaction from the DEPOSITOR_ACCOUNT. -Interface -setHolocene -This function is meant to be called once on the activation block of the holocene network upgrade. -It MUST only be callable by the DEPOSITOR_ACCOUNT once. When it is called, it MUST call -call each getter for the network specific config and set the returndata into storage. -setConfig -This function MUST only be callable by the DEPOSITOR_ACCOUNT. It modifies the storage directly -of the L1Block contract. It MUST handle all defined ConfigTypes. To ensure a simple ABI, the -bytes value MUST be abi decoded based on the ConfigType. -function setConfig(ConfigType,bytes) - -Note that ConfigType is an enum which is an alias for a uint8. -baseFeeVaultConfig -This function MUST be called by the BaseFeeVault to fetch network specific configuration. -function baseFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -sequencerFeeVaultConfig -This function MUST be called by the SequencerFeeVault to fetch network specific configuration. -function sequencerFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1FeeVaultConfig -This function MUST be called by the L1FeeVault to fetch network specific configuration. -function l1FeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1CrossDomainMessenger -This function MUST be called by the L2CrossDomainMessenger to fetch the address of the L1CrossDomainMessenger. -function l1CrossDomainMessenger()(address) - -l1StandardBridge -This function MUST be called by the L2StandardBridge to fetch the address of the L2CrossDomainMessenger. -function l1StandardBridge()(address) - -l1ERC721Bridge -This function MUST be called by the L2ERC721Bridge to fetch the address of the L1ERC721Bridge. -function l1ERC721Bridge()(address) - -remoteChainId -This function MUST be called by the OptimismMintableERC721Factory to fetch the chain id of the remote chain. -For an L2, this is the L1 chain id. -function remoteChainId()(uint256) - -FeeVault -The following changes apply to each of the BaseFeeVault, the L1FeeVault and the SequencerFeeVault. -Interface -The following functions are updated to read from the L1Block contract: - -recipient()(address) -withdrawalNetwork()(WithdrawalNetwork) -minWithdrawalAmount()(uint256) -withdraw() - -NameCall -BaseFeeVaultL1Block.baseFeeVaultConfig() -SequencerFeeVaultL1Block.sequencerFeeVaultConfig() -L1FeeVaultL1Block.l1FeeVaultConfig() - - -config -A new function is added to fetch the full Fee Vault Config. -function config()(address,uint256,WithdrawalNetwork) - -L2CrossDomainMessenger -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1CrossDomainMessenger(): - -otherMessenger()(address) -OTHER_MESSENGER()(address) - -L2ERC721Bridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1ERC721Bridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -L2StandardBridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1StandardBridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -OptimismMintableERC721Factory -The chain id is no longer read from storage but instead is read from the L1Block contract by calling -L1Block.remoteChainId() -Security Considerations -GovernanceToken -The predeploy defined by GovernanceToken should be an empty account until it is defined by -a future hardfork. +Predeploys @@ -401,7 +199,7 @@ GovernanceTok - + @@ -415,7 +213,7 @@ GovernanceTok - + diff --git a/protocol/holocene/configurability.html b/protocol/holocene/system-config.html similarity index 72% rename from protocol/holocene/configurability.html rename to protocol/holocene/system-config.html index 985283b56..0df792e3e 100644 --- a/protocol/holocene/configurability.html +++ b/protocol/holocene/system-config.html @@ -3,7 +3,7 @@ - Configurability - OP Stack Specification + System Config - OP Stack Specification @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -159,7 +159,7 @@ OP Stack Specification - + @@ -189,18 +189,12 @@ OP Stack Specification -Configurability +System Config Table of Contents -Overview -Constants - -ConfigType - - -SystemConfig +Overview ConfigUpdate Initialization @@ -214,22 +208,6 @@ Configurabili eip1559Denominator -Fee Vault Config - -setBaseFeeVaultConfig -setL1FeeVaultConfig -setSequencerFeeVaultConfig - - - - - - -OptimismPortal - -Interface - -setConfig @@ -237,23 +215,7 @@ Configurabili Overview -The SystemConfig and OptimismPortal are updated with a new flow for chain -configurability. -Constants -ConfigType -The ConfigType enum represents configuration that can be modified. -NameValueDescription -SET_GAS_PAYING_TOKENuint8(0)Modifies the gas paying token for the chain -SET_BASE_FEE_VAULT_CONFIGuint8(1)Sets the Fee Vault Config for the BaseFeeVault -SET_L1_FEE_VAULT_CONFIGuint8(2)Sets the Fee Vault Config for the L1FeeVault -SET_SEQUENCER_FEE_VAULT_CONFIGuint8(3)Sets the Fee Vault Config for the SequencerFeeVault -SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESSuint8(4)Sets the L1CrossDomainMessenger address -SET_L1_ERC_721_BRIDGE_ADDRESSuint8(5)Sets the L1ERC721Bridge address -SET_L1_STANDARD_BRIDGE_ADDRESSuint8(6)Sets the L1StandardBridge address -SET_REMOTE_CHAIN_IDuint8(7)Sets the chain id of the base chain - - -SystemConfig +The SystemConfig is updated to allow for dynamic EIP-1559 parameters. ConfigUpdate The following ConfigUpdate event is defined where the CONFIG_VERSION is uint256(0): NameValueDefinitionUsage @@ -272,16 +234,7 @@ Initialization< emit ConfigUpdate.GAS_LIMIT emit ConfigUpdate.UNSAFE_BLOCK_SIGNER emit ConfigUpdate.EIP_1559_PARAMS -setConfig(SET_GAS_PAYING_TOKEN) -setConfig(SET_BASE_FEE_VAULT_CONFIG) -setConfig(SET_L1_FEE_VAULT_CONFIG) -setConfig(SET_SEQUENCER_FEE_VAULT_CONFIG) -setConfig(SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESS) -setConfig(SET_L1_ERC_721_BRIDGE_ADDRESS) -setConfig(SET_L1_STANDARD_BRIDGE_ADDRESS) -setConfig(SET_REMOTE_CHAIN_ID) -These actions MAY only be triggered if there is a diff to the value. Modifying EIP-1559 Parameters A new SystemConfig UpdateType is introduced that enables the modification of EIP-1559 parameters. This allows for the chain @@ -302,39 +255,6 @@ e This function returns the currently configured EIP-1559 denominator. function eip1559Denominator()(uint64) -Fee Vault Config -For each FeeVault, there is a setter for its config. The arguments to the setter include -the RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork. -Each of these functions should be public and only callable by the chain governor. -Each function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType. -setBaseFeeVaultConfig -function setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork) - -setL1FeeVaultConfig -function setL1FeeVaultConfig(address,uint256,WithdrawalNetwork) - -setSequencerFeeVaultConfig -function setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork) - -OptimismPortal -The OptimismPortal is updated to emit a special system TransactionDeposited event. -Interface -setConfig -The setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig -is the single source of truth for chain operator ownership. -function setConfig(ConfigType,bytes) - -This function emits a TransactionDeposited event. -event TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData); - -The following fields are included: - -from is the DEPOSITOR_ACCOUNT -to is Predeploys.L1Block -version is uint256(0) -opaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit -is 200_000, isCreation is false and the data is abi.encodeCall(L1Block.setConfig, (_type, _value)) - diff --git a/protocol/messengers.html b/protocol/messengers.html index 5719b0eac..b0c6745a4 100644 --- a/protocol/messengers.html +++ b/protocol/messengers.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/overview.html b/protocol/overview.html index 19a171b6b..8d974911d 100644 --- a/protocol/overview.html +++ b/protocol/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/precompiles.html b/protocol/precompiles.html index 2636bcded..591225781 100644 --- a/protocol/precompiles.html +++ b/protocol/precompiles.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/predeploys.html b/protocol/predeploys.html index f69344d63..18f80ecc9 100644 --- a/protocol/predeploys.html +++ b/protocol/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/preinstalls.html b/protocol/preinstalls.html index a3e678702..de25cd1f4 100644 --- a/protocol/preinstalls.html +++ b/protocol/preinstalls.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/proposals.html b/protocol/proposals.html index 4356aed7b..c7e27aba0 100644 --- a/protocol/proposals.html +++ b/protocol/proposals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/regolith/overview.html b/protocol/regolith/overview.html index 25fb28a59..735c8d392 100644 --- a/protocol/regolith/overview.html +++ b/protocol/regolith/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node-p2p.html b/protocol/rollup-node-p2p.html index 6b7b877ad..f733fce32 100644 --- a/protocol/rollup-node-p2p.html +++ b/protocol/rollup-node-p2p.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node.html b/protocol/rollup-node.html index 7b2194855..74e7465df 100644 --- a/protocol/rollup-node.html +++ b/protocol/rollup-node.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/safe-extensions.html b/protocol/safe-extensions.html index c13615619..4601198ba 100644 --- a/protocol/safe-extensions.html +++ b/protocol/safe-extensions.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/stage-1.html b/protocol/stage-1.html index d28f06461..2659aa26c 100644 --- a/protocol/stage-1.html +++ b/protocol/stage-1.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-configuration.html b/protocol/superchain-configuration.html index ee7a3f560..6796bb40e 100644 --- a/protocol/superchain-configuration.html +++ b/protocol/superchain-configuration.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-upgrades.html b/protocol/superchain-upgrades.html index e9ac90b28..aad45a9b2 100644 --- a/protocol/superchain-upgrades.html +++ b/protocol/superchain-upgrades.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/system-config.html b/protocol/system-config.html index afbdefd92..d5fe843f1 100644 --- a/protocol/system-config.html +++ b/protocol/system-config.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/withdrawals.html b/protocol/withdrawals.html index e390c5450..8596661a9 100644 --- a/protocol/withdrawals.html +++ b/protocol/withdrawals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/root.html b/root.html index 20d712d67..bd978d50b 100644 --- a/root.html +++ b/root.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/searchindex.js b/searchindex.js index 371b06267..623744500 100644 --- a/searchindex.js +++ b/searchindex.js @@ -1 +1 @@ -Object.assign(window.search, {"doc_urls":["root.html#op-stack-specification","root.html#about-optimism","root.html#about-the-op-stack","root.html#site-navigation","background.html#background","background.html#overview","background.html#foundations","background.html#ethereum-scalability","background.html#optimistic-rollups","background.html#evm-equivalence","background.html#protocol-guarantees","background.html#liveness","background.html#validity","background.html#availability","background.html#network-participants","background.html#users","background.html#sequencers","background.html#verifiers","background.html#key-interaction-diagrams","background.html#depositing-and-sending-transactions","background.html#withdrawing","background.html#next-steps","protocol/overview.html#optimism-overview","protocol/overview.html#architecture-design-goals","protocol/overview.html#architecture-overview","protocol/overview.html#core-l1-smart-contracts","protocol/overview.html#core-l2-smart-contracts","protocol/overview.html#smart-contract-proxies","protocol/overview.html#l2-node-components","protocol/overview.html#transactionblock-propagation","protocol/overview.html#key-interactions-in-depth","protocol/overview.html#deposits","protocol/overview.html#block-derivation","protocol/overview.html#engine-api","protocol/bridges.html#standard-bridges","protocol/bridges.html#overview","protocol/bridges.html#token-depositing","protocol/bridges.html#upgradability","protocol/messengers.html#cross-domain-messengers","protocol/messengers.html#overview","protocol/messengers.html#message-passing","protocol/messengers.html#upgradability","protocol/messengers.html#message-versioning","protocol/messengers.html#message-version-0","protocol/messengers.html#message-version-1","protocol/messengers.html#backwards-compatibility-notes","protocol/deposits.html#deposits","protocol/deposits.html#overview","protocol/deposits.html#the-deposited-transaction-type","protocol/deposits.html#source-hash-computation","protocol/deposits.html#kinds-of-deposited-transactions","protocol/deposits.html#validation-and-authorization-of-deposited-transactions","protocol/deposits.html#execution","protocol/deposits.html#deposit-receipt","protocol/deposits.html#l1-attributes-deposited-transaction","protocol/deposits.html#l1-attributes-deposited-transaction-calldata","protocol/deposits.html#special-accounts-on-l2","protocol/deposits.html#l1-attributes-depositor-account","protocol/deposits.html#l1-attributes-predeployed-contract","protocol/deposits.html#user-deposited-transactions","protocol/deposits.html#deposit-contract","protocol/withdrawals.html#withdrawals","protocol/withdrawals.html#overview","protocol/withdrawals.html#withdrawal-flow","protocol/withdrawals.html#on-l2","protocol/withdrawals.html#on-l1","protocol/withdrawals.html#the-l2tol1messagepasser-contract","protocol/withdrawals.html#addresses-are-not-aliased-on-withdrawals","protocol/withdrawals.html#the-optimism-portal-contract","protocol/withdrawals.html#withdrawal-verification-and-finalization","protocol/withdrawals.html#security-considerations","protocol/withdrawals.html#key-properties-of-withdrawal-verification","protocol/withdrawals.html#handling-successfully-verified-messages-that-fail-when-relayed","protocol/withdrawals.html#optimismportal-can-send-arbitrary-messages-on-l1","protocol/guaranteed-gas-market.html#guaranteed-gas-fee-market","protocol/guaranteed-gas-market.html#overview","protocol/guaranteed-gas-market.html#gas-stipend","protocol/guaranteed-gas-market.html#default-values","protocol/guaranteed-gas-market.html#limiting-guaranteed-gas","protocol/guaranteed-gas-market.html#rationale-for-burning-l1-gas","protocol/guaranteed-gas-market.html#on-preventing-griefing-attacks","protocol/proposals.html#l2-output-root-proposals-specification","protocol/proposals.html#overview","protocol/proposals.html#proposing-l2-output-commitments","protocol/proposals.html#l2outputoracle-v100","protocol/proposals.html#l2-output-commitment-construction","protocol/proposals.html#l2-output-oracle-smart-contract","protocol/proposals.html#configuration","protocol/proposals.html#security-considerations","protocol/proposals.html#l1-reorgs","protocol/exec-engine.html#l2-execution-engine","protocol/exec-engine.html#1559-parameters","protocol/exec-engine.html#deposited-transaction-processing","protocol/exec-engine.html#deposited-transaction-boundaries","protocol/exec-engine.html#fees","protocol/exec-engine.html#fee-vaults","protocol/exec-engine.html#priority-fees-sequencer-fee-vault","protocol/exec-engine.html#base-fees-base-fee-vault","protocol/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/exec-engine.html#engine-api","protocol/exec-engine.html#engine_forkchoiceupdatedv2","protocol/exec-engine.html#engine_forkchoiceupdatedv3","protocol/exec-engine.html#engine_newpayloadv2","protocol/exec-engine.html#engine_newpayloadv3","protocol/exec-engine.html#engine_getpayloadv2","protocol/exec-engine.html#engine_getpayloadv3","protocol/exec-engine.html#engine_signalsuperchainv1","protocol/exec-engine.html#networking","protocol/exec-engine.html#sync","protocol/exec-engine.html#happy-path-sync","protocol/exec-engine.html#worst-case-sync","protocol/exec-engine.html#ecotone-disable-blob-transactions","protocol/exec-engine.html#ecotone-beacon-block-root","protocol/exec-engine.html#p2p-modifications","protocol/rollup-node.html#rollup-node-specification","protocol/rollup-node.html#overview","protocol/rollup-node.html#driver","protocol/rollup-node.html#derivation","protocol/rollup-node.html#l2-output-rpc-method","protocol/rollup-node.html#structures","protocol/rollup-node.html#output-method-api","protocol/rollup-node.html#protocol-version-tracking","protocol/rollup-node-p2p.html#rollup-node-p2p-interface","protocol/rollup-node-p2p.html#overview","protocol/rollup-node-p2p.html#p2p-configuration","protocol/rollup-node-p2p.html#identification","protocol/rollup-node-p2p.html#discv5","protocol/rollup-node-p2p.html#libp2p","protocol/rollup-node-p2p.html#gossip-topics","protocol/rollup-node-p2p.html#blocksv1","protocol/rollup-node-p2p.html#blocksv2","protocol/rollup-node-p2p.html#blocksv3","protocol/rollup-node-p2p.html#block-encoding","protocol/rollup-node-p2p.html#block-signatures","protocol/rollup-node-p2p.html#block-validation","protocol/rollup-node-p2p.html#req-resp","protocol/rollup-node-p2p.html#payload_by_number","protocol/derivation.html#l2-chain-derivation-specification","protocol/derivation.html#overview","protocol/derivation.html#eager-block-derivation","protocol/derivation.html#protocol-parameters","protocol/derivation.html#batch-submission","protocol/derivation.html#sequencing--batch-submission-overview","protocol/derivation.html#batch-submission-wire-format","protocol/derivation.html#batcher-transaction-format","protocol/derivation.html#frame-format","protocol/derivation.html#channel-format","protocol/derivation.html#batch-format","protocol/derivation.html#architecture","protocol/derivation.html#l2-chain-derivation-pipeline","protocol/derivation.html#l1-traversal","protocol/derivation.html#l1-retrieval","protocol/derivation.html#frame-queue","protocol/derivation.html#channel-bank","protocol/derivation.html#channel-reader-batch-decoding","protocol/derivation.html#batch-queue","protocol/derivation.html#payload-attributes-derivation","protocol/derivation.html#engine-queue","protocol/derivation.html#resetting-the-pipeline","protocol/derivation.html#deriving-payload-attributes","protocol/derivation.html#deriving-the-transaction-list","protocol/derivation.html#network-upgrade-automation-transactions","protocol/derivation.html#building-individual-payload-attributes","protocol/batcher.html#batch-submitter","protocol/batcher.html#overview","fault-proof/index.html#fault-proof","fault-proof/index.html#overview","fault-proof/index.html#pre-image-oracle","fault-proof/index.html#pre-image-key-types","fault-proof/index.html#bootstrapping","fault-proof/index.html#hinting","fault-proof/index.html#pre-image-communication","fault-proof/index.html#fault-proof-program","fault-proof/index.html#prologue","fault-proof/index.html#main-content","fault-proof/index.html#epilogue","fault-proof/index.html#pre-image-hinting-routes","fault-proof/index.html#precompile-accelerators","fault-proof/index.html#fault-proof-vm","fault-proof/index.html#fault-proof-interactive-dispute-game","fault-proof/cannon-fault-proof-vm.html#cannon-fault-proof-virtual-machine","fault-proof/cannon-fault-proof-vm.html#overview","fault-proof/cannon-fault-proof-vm.html#state","fault-proof/cannon-fault-proof-vm.html#state-hash","fault-proof/cannon-fault-proof-vm.html#memory","fault-proof/cannon-fault-proof-vm.html#heap","fault-proof/cannon-fault-proof-vm.html#delay-slots","fault-proof/cannon-fault-proof-vm.html#syscalls","fault-proof/cannon-fault-proof-vm.html#io","fault-proof/cannon-fault-proof-vm.html#standard-streams","fault-proof/cannon-fault-proof-vm.html#hint-communication","fault-proof/cannon-fault-proof-vm.html#pre-image-communication","fault-proof/cannon-fault-proof-vm.html#exceptions","fault-proof/cannon-fault-proof-vm.html#security-model","fault-proof/cannon-fault-proof-vm.html#compiler-correctness","fault-proof/cannon-fault-proof-vm.html#compiler-assumptions","fault-proof/stage-one/index.html#stage-one-decentralization","fault-proof/stage-one/dispute-game-interface.html#dispute-game-interface","fault-proof/stage-one/dispute-game-interface.html#overview","fault-proof/stage-one/dispute-game-interface.html#types","fault-proof/stage-one/dispute-game-interface.html#disputegamefactory-interface","fault-proof/stage-one/dispute-game-interface.html#disputegame-interface","fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game","fault-proof/stage-one/fault-dispute-game.html#overview","fault-proof/stage-one/fault-dispute-game.html#definitions","fault-proof/stage-one/fault-dispute-game.html#virtual-machine-vm","fault-proof/stage-one/fault-dispute-game.html#preimageoracle","fault-proof/stage-one/fault-dispute-game.html#execution-trace","fault-proof/stage-one/fault-dispute-game.html#claims","fault-proof/stage-one/fault-dispute-game.html#anchor-state","fault-proof/stage-one/fault-dispute-game.html#anchor-state-registry","fault-proof/stage-one/fault-dispute-game.html#dag","fault-proof/stage-one/fault-dispute-game.html#subgame","fault-proof/stage-one/fault-dispute-game.html#game-tree","fault-proof/stage-one/fault-dispute-game.html#position","fault-proof/stage-one/fault-dispute-game.html#max_clock_duration","fault-proof/stage-one/fault-dispute-game.html#clock_extension","fault-proof/stage-one/fault-dispute-game.html#freeloader-claims","fault-proof/stage-one/fault-dispute-game.html#core-game-mechanics","fault-proof/stage-one/fault-dispute-game.html#actors","fault-proof/stage-one/fault-dispute-game.html#moves","fault-proof/stage-one/fault-dispute-game.html#l2-block-number-challenge","fault-proof/stage-one/fault-dispute-game.html#step","fault-proof/stage-one/fault-dispute-game.html#step-types","fault-proof/stage-one/fault-dispute-game.html#preimageoracle-interaction","fault-proof/stage-one/fault-dispute-game.html#team-dynamics","fault-proof/stage-one/fault-dispute-game.html#game-clock","fault-proof/stage-one/fault-dispute-game.html#resolution","fault-proof/stage-one/fault-dispute-game.html#finalization","fault-proof/stage-one/honest-challenger-fdg.html#honest-challenger-fault-dispute-game","fault-proof/stage-one/honest-challenger-fdg.html#overview","fault-proof/stage-one/honest-challenger-fdg.html#invariants","fault-proof/stage-one/honest-challenger-fdg.html#fault-dispute-game-responses","fault-proof/stage-one/honest-challenger-fdg.html#moves","fault-proof/stage-one/honest-challenger-fdg.html#steps","fault-proof/stage-one/honest-challenger-fdg.html#timeliness","fault-proof/stage-one/honest-challenger-fdg.html#resolution","fault-proof/stage-one/bond-incentives.html#bond-incentives","fault-proof/stage-one/bond-incentives.html#overview","fault-proof/stage-one/bond-incentives.html#moves","fault-proof/stage-one/bond-incentives.html#subgame-resolution","fault-proof/stage-one/bond-incentives.html#leftmost-claim-incentives","fault-proof/stage-one/bond-incentives.html#fault-proof-mainnet-incentives","fault-proof/stage-one/bond-incentives.html#authenticated-roles","fault-proof/stage-one/bond-incentives.html#base-fee-assumption","fault-proof/stage-one/bond-incentives.html#bond-scaling","fault-proof/stage-one/bond-incentives.html#required-bond-formula","fault-proof/stage-one/bond-incentives.html#other-incentives","fault-proof/stage-one/bond-incentives.html#delayedweth","fault-proof/stage-one/bridge-integration.html#bridge-integration","fault-proof/stage-one/bridge-integration.html#overview","fault-proof/stage-one/bridge-integration.html#legacy-semantics","fault-proof/stage-one/bridge-integration.html#fpac-optimismportal-mods-specification","fault-proof/stage-one/bridge-integration.html#roles---optimismportal","fault-proof/stage-one/bridge-integration.html#new-deployconfig-variables","fault-proof/stage-one/bridge-integration.html#data-structures","fault-proof/stage-one/bridge-integration.html#state-layout","fault-proof/stage-one/bridge-integration.html#provewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#finalizewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#air-gap","fault-proof/stage-one/bridge-integration.html#proxy-upgrade","fault-proof/stage-one/bridge-integration.html#permissioned-faultdisputegame","fault-proof/stage-one/bridge-integration.html#roles---permissioneddisputegame","fault-proof/stage-one/bridge-integration.html#modifications","protocol/precompiles.html#precompiles","protocol/precompiles.html#overview","protocol/precompiles.html#p256verify","protocol/predeploys.html#predeploys","protocol/predeploys.html#overview","protocol/predeploys.html#legacymessagepasser","protocol/predeploys.html#l2tol1messagepasser","protocol/predeploys.html#deployerwhitelist","protocol/predeploys.html#legacyerc20eth","protocol/predeploys.html#weth9","protocol/predeploys.html#l2crossdomainmessenger","protocol/predeploys.html#l2standardbridge","protocol/predeploys.html#l1blocknumber","protocol/predeploys.html#gaspriceoracle","protocol/predeploys.html#l1block","protocol/predeploys.html#proxyadmin","protocol/predeploys.html#sequencerfeevault","protocol/predeploys.html#optimismmintableerc20factory","protocol/predeploys.html#optimismmintableerc721factory","protocol/predeploys.html#basefeevault","protocol/predeploys.html#l1feevault","protocol/predeploys.html#schemaregistry","protocol/predeploys.html#eas","protocol/predeploys.html#beacon-block-root","protocol/preinstalls.html#preinstalls","protocol/preinstalls.html#overview","protocol/preinstalls.html#safe","protocol/preinstalls.html#safel2","protocol/preinstalls.html#multisend","protocol/preinstalls.html#multisendcallonly","protocol/preinstalls.html#safesingletonfactory","protocol/preinstalls.html#multicall3","protocol/preinstalls.html#create2deployer","protocol/preinstalls.html#createx","protocol/preinstalls.html#arachnids-deterministic-deployment-proxy","protocol/preinstalls.html#permit2","protocol/preinstalls.html#erc-4337-v060-entrypoint","protocol/preinstalls.html#erc-4337-v060-sendercreator","protocol/preinstalls.html#erc-4337-v070-entrypoint","protocol/preinstalls.html#erc-4337-v070-sendercreator","protocol/superchain-configuration.html#superchain-configuration","protocol/superchain-configuration.html#overview","protocol/superchain-configuration.html#configurable-values","protocol/superchain-configuration.html#configuration-data-flow","protocol/superchain-configuration.html#pausability","protocol/superchain-upgrades.html#superchain-upgrades","protocol/superchain-upgrades.html#overview","protocol/superchain-upgrades.html#protocol-version","protocol/superchain-upgrades.html#protocol-version-format","protocol/superchain-upgrades.html#protocol-version-exposure","protocol/superchain-upgrades.html#superchain-target","protocol/superchain-upgrades.html#superchain-version-signaling","protocol/superchain-upgrades.html#protocolversions-l1-contract","protocol/superchain-upgrades.html#activation-rules","protocol/superchain-upgrades.html#l2-block-number-based-activation-deprecated","protocol/superchain-upgrades.html#l2-block-timestamp-based-activation","protocol/superchain-upgrades.html#op-stack-protocol-versions","protocol/superchain-upgrades.html#post-bedrock-network-upgrades","protocol/superchain-upgrades.html#activation-timestamps","protocol/system-config.html#system-config","protocol/system-config.html#overview","protocol/system-config.html#system-config-contents-version-0","protocol/system-config.html#batcherhash-bytes32","protocol/system-config.html#scalars","protocol/system-config.html#gaslimit-uint64","protocol/system-config.html#unsafeblocksigner-address","protocol/system-config.html#writing-the-system-config","protocol/system-config.html#reading-the-system-config","protocol/configurability.html#op-stack-configurability","protocol/configurability.html#consensus-parameters","protocol/configurability.html#batch-inbox-address","protocol/configurability.html#batcher-hash","protocol/configurability.html#chain-id","protocol/configurability.html#proof-maturity-delay","protocol/configurability.html#dispute-game-finality","protocol/configurability.html#respected-game-type","protocol/configurability.html#fault-game-max-depth","protocol/configurability.html#fault-game-split-depth","protocol/configurability.html#max-game-clock-duration","protocol/configurability.html#game-clock-extension","protocol/configurability.html#bond-withdrawal-delay","protocol/configurability.html#minimum-large-preimage-proposal-size","protocol/configurability.html#large-preimage-proposal-challenge-period","protocol/configurability.html#fault-game-absolute-prestate","protocol/configurability.html#fault-game-genesis-block","protocol/configurability.html#fault-game-genesis-output-root","protocol/configurability.html#fee-scalar","protocol/configurability.html#gas-limit","protocol/configurability.html#genesis-state","protocol/configurability.html#l2-block-time","protocol/configurability.html#resource-config","protocol/configurability.html#sequencing-window-size","protocol/configurability.html#start-block","protocol/configurability.html#superchain-target","protocol/configurability.html#governance-token","protocol/configurability.html#resource-config-1","protocol/configurability.html#policy-parameters","protocol/configurability.html#data-availability-type","protocol/configurability.html#batch-submission-frequency","protocol/configurability.html#output-frequency","protocol/configurability.html#admin-roles","protocol/configurability.html#l1-proxy-admin","protocol/configurability.html#l1-proxyadmin-owner","protocol/configurability.html#l2-proxy-admin","protocol/configurability.html#l2-proxyadmin-owner","protocol/configurability.html#system-config-owner","protocol/configurability.html#service-roles","protocol/configurability.html#batch-submitter-address","protocol/configurability.html#challenger-address","protocol/configurability.html#guardian-address","protocol/configurability.html#proposer-address","protocol/configurability.html#sequencer-p2p--unsafe-head-signer","protocol/safe-extensions.html#safe-contract-extensions","protocol/safe-extensions.html#guardian-safe","protocol/safe-extensions.html#deputy-guardian-module","protocol/safe-extensions.html#deputy-guardian-module-security-properties","protocol/safe-extensions.html#security-council-liveness-checking-extensions","protocol/safe-extensions.html#the-liveness-guard","protocol/safe-extensions.html#the-liveness-module","protocol/safe-extensions.html#owner-removal-call-flow","protocol/safe-extensions.html#shutdown","protocol/safe-extensions.html#liveness-security-properties","protocol/safe-extensions.html#interdependency-between-the-liveness-guard-and-liveness-module","protocol/safe-extensions.html#operational-considerations","protocol/safe-extensions.html#manual-validation-of-new-owner-liveness","protocol/safe-extensions.html#deploying-the-liveness-checking-system","protocol/safe-extensions.html#modifying-the-liveness-checking-system","protocol/stage-1.html#stage-1-roles-and-requirements","protocol/stage-1.html#overview","protocol/stage-1.html#permissionless-fault-proofs","protocol/stage-1.html#roles-for-stage-1","protocol/stage-1.html#configuration-of-safes","protocol/stage-1.html#ownership-model-diagram","protocol/regolith/overview.html#regolith","protocol/regolith/overview.html#overview","protocol/canyon/overview.html#canyon","protocol/canyon/overview.html#execution-layer","protocol/canyon/overview.html#consensus-layer","protocol/delta/overview.html#delta","protocol/delta/overview.html#consensus-layer","protocol/delta/span-batches.html#span-batches","protocol/delta/span-batches.html#introduction","protocol/delta/span-batches.html#span-batch-format","protocol/delta/span-batches.html#span-batch-size-limits","protocol/delta/span-batches.html#future-batch-format-extension","protocol/delta/span-batches.html#span-batch-activation-rule","protocol/delta/span-batches.html#optimization-strategies","protocol/delta/span-batches.html#truncating-information-and-storing-only-necessary-data","protocol/delta/span-batches.html#tx_data_headers-removal-from-initial-specs","protocol/delta/span-batches.html#chain-id-removal-from-initial-specs","protocol/delta/span-batches.html#reorganization-of-constant-length-transaction-fields","protocol/delta/span-batches.html#rlp-encoding-for-only-variable-length-fields","protocol/delta/span-batches.html#store-y_parity-and-protected_bit-instead-of-v","protocol/delta/span-batches.html#adjust-txs-data-layout-for-better-compression","protocol/delta/span-batches.html#fee_recipients-encoding-scheme","protocol/delta/span-batches.html#how-derivation-works-with-span-batches","protocol/delta/span-batches.html#integration","protocol/delta/span-batches.html#channel-reader-batch-decoding","protocol/delta/span-batches.html#batch-queue","protocol/delta/span-batches.html#batcher","protocol/ecotone/overview.html#ecotone-network-upgrade","protocol/ecotone/overview.html#execution-layer","protocol/ecotone/overview.html#consensus-layer","protocol/ecotone/derivation.html#derivation","protocol/ecotone/derivation.html#ecotone-blob-retrieval","protocol/ecotone/derivation.html#blob-encoding","protocol/ecotone/l1-attributes.html#ecotone-l1-attributes","protocol/ecotone/l1-attributes.html#overview","protocol/ecotone/l1-attributes.html#l1-attributes-predeployed-contract","protocol/ecotone/l1-attributes.html#ecotone-l1block-upgrade","protocol/fjord/overview.html#fjord-network-upgrade","protocol/fjord/overview.html#execution-layer","protocol/fjord/overview.html#consensus-layer","protocol/fjord/exec-engine.html#l2-execution-engine","protocol/fjord/exec-engine.html#fees","protocol/fjord/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/fjord/exec-engine.html#l1-gas-usage-estimation","protocol/fjord/derivation.html#fjord-l2-chain-derivation-changes","protocol/fjord/derivation.html#protocol-parameter-changes","protocol/fjord/derivation.html#timestamp-activation","protocol/fjord/derivation.html#constant-maximum-sequencer-drift","protocol/fjord/derivation.html#rationale","protocol/fjord/derivation.html#security-considerations","protocol/fjord/derivation.html#increasing-max_rlp_bytes_per_channel-and-max_channel_bank_size","protocol/fjord/derivation.html#rationale-1","protocol/fjord/derivation.html#security-considerations-1","protocol/fjord/derivation.html#brotli-channel-compression","protocol/fjord/derivation.html#network-upgrade-automation-transactions","protocol/fjord/derivation.html#gaspriceoracle-deployment","protocol/fjord/derivation.html#gaspriceoracle-proxy-update","protocol/fjord/derivation.html#gaspriceoracle-enable-fjord","protocol/fjord/predeploys.html#predeploys","protocol/fjord/predeploys.html#gaspriceoracle","protocol/fjord/predeploys.html#l1-gas-usage-estimation","protocol/granite/overview.html#granite-network-upgrade","protocol/granite/overview.html#execution-layer","protocol/granite/overview.html#consensus-layer","protocol/granite/exec-engine.html#l2-execution-engine","protocol/granite/exec-engine.html#evm-changes","protocol/granite/exec-engine.html#bn256pairing-precompile-input-restriction","protocol/granite/derivation.html#granite-l2-chain-derivation-changes","protocol/granite/derivation.html#protocol-parameter-changes","protocol/granite/derivation.html#reduce-channel-timeout","protocol/holocene/overview.html#holocene-network-upgrade","protocol/holocene/overview.html#execution-layer","protocol/holocene/overview.html#consensus-layer","protocol/holocene/overview.html#smart-contracts","protocol/holocene/derivation.html#holocene-l2-chain-derivation-changes","protocol/holocene/derivation.html#holocene-derivation","protocol/holocene/derivation.html#summary","protocol/holocene/derivation.html#frame-queue","protocol/holocene/derivation.html#channel-bank","protocol/holocene/derivation.html#pruning","protocol/holocene/derivation.html#timeout","protocol/holocene/derivation.html#reading--frame-loading","protocol/holocene/derivation.html#span-batches","protocol/holocene/derivation.html#batch-queue","protocol/holocene/derivation.html#fast-channel-invalidation","protocol/holocene/derivation.html#engine-queue","protocol/holocene/derivation.html#attributes-builder","protocol/holocene/derivation.html#activation","protocol/holocene/derivation.html#rationale","protocol/holocene/derivation.html#strict-frame-and-batch-ordering","protocol/holocene/derivation.html#partial-span-batch-validity","protocol/holocene/derivation.html#fast-channel-invalidation-1","protocol/holocene/derivation.html#steady-block-derivation","protocol/holocene/derivation.html#less-defensive-protocol","protocol/holocene/derivation.html#security-and-implementation-considerations","protocol/holocene/derivation.html#reorgs","protocol/holocene/derivation.html#batcher-hardening","protocol/holocene/derivation.html#sync-start","protocol/holocene/exec-engine.html#l2-execution-engine","protocol/holocene/exec-engine.html#timestamp-activation","protocol/holocene/exec-engine.html#l2tol1messagepasser-storage-root-in-header","protocol/holocene/exec-engine.html#header-validity-rules","protocol/holocene/exec-engine.html#header-withdrawals-root","protocol/holocene/exec-engine.html#extended-payloadattributesv3","protocol/holocene/exec-engine.html#eip1559params-encoding","protocol/holocene/exec-engine.html#execution","protocol/holocene/exec-engine.html#rationale","protocol/holocene/exec-engine.html#eip1559params-in-header","protocol/holocene/exec-engine.html#header-validity-rules-1","protocol/holocene/exec-engine.html#encoding","protocol/holocene/exec-engine.html#rationale-1","protocol/holocene/predeploys.html#overview","protocol/holocene/predeploys.html#constants","protocol/holocene/predeploys.html#predeploys","protocol/holocene/predeploys.html#l1block","protocol/holocene/predeploys.html#feevault","protocol/holocene/predeploys.html#l2crossdomainmessenger","protocol/holocene/predeploys.html#l2erc721bridge","protocol/holocene/predeploys.html#l2standardbridge","protocol/holocene/predeploys.html#optimismmintableerc721factory","protocol/holocene/predeploys.html#security-considerations","protocol/holocene/predeploys.html#governancetoken","protocol/holocene/configurability.html#configurability","protocol/holocene/configurability.html#overview","protocol/holocene/configurability.html#constants","protocol/holocene/configurability.html#configtype","protocol/holocene/configurability.html#systemconfig","protocol/holocene/configurability.html#configupdate","protocol/holocene/configurability.html#initialization","protocol/holocene/configurability.html#modifying-eip-1559-parameters","protocol/holocene/configurability.html#interface","protocol/holocene/configurability.html#optimismportal","protocol/holocene/configurability.html#interface-1","governance/gov-token.html#governance-token","governance/gov-token.html#overview","governance/gov-token.html#token-minting","governance/gov-token.html#token-burning","governance/gov-token.html#voting-power","governance/gov-token.html#delegation","experimental/custom-gas-token.html#custom-gas-token","experimental/custom-gas-token.html#overview","experimental/custom-gas-token.html#constants","experimental/custom-gas-token.html#properties-of-a-gas-paying-token","experimental/custom-gas-token.html#automated-validation","experimental/custom-gas-token.html#configuring-the-gas-paying-token","experimental/custom-gas-token.html#contract-modifications","experimental/custom-gas-token.html#igastoken-interface","experimental/custom-gas-token.html#gas-token-aware","experimental/custom-gas-token.html#optimismportal","experimental/custom-gas-token.html#standardbridge","experimental/custom-gas-token.html#crossdomainmessenger","experimental/custom-gas-token.html#systemconfig","experimental/custom-gas-token.html#l1block","experimental/custom-gas-token.html#weth9","experimental/custom-gas-token.html#user-flow","experimental/custom-gas-token.html#when-eth-is-the-native-asset","experimental/custom-gas-token.html#when-an-erc20-token-is-the-native-asset","experimental/custom-gas-token.html#differences","experimental/custom-gas-token.html#upgrade","experimental/custom-gas-token.html#l1block-deployment","experimental/custom-gas-token.html#l2crossdomainmessenger-deployment","experimental/custom-gas-token.html#l2standardbridge-deployment","experimental/custom-gas-token.html#l1block-proxy-update","experimental/custom-gas-token.html#l2crossdomainmessenger-proxy-update","experimental/custom-gas-token.html#l2standardbridge-proxy-update","experimental/custom-gas-token.html#selection-of-ether_token_address","experimental/custom-gas-token.html#standard-config","experimental/custom-gas-token.html#fees","experimental/custom-gas-token.html#security-considerations","experimental/custom-gas-token.html#optimismportal-token-allowance","experimental/custom-gas-token.html#interoperability-support","experimental/custom-gas-token.html#wrapped-ether","experimental/alt-da.html#alt-da-mode","experimental/alt-da.html#overview","experimental/alt-da.html#input-commitment-submission","experimental/alt-da.html#da-server","experimental/alt-da.html#data-availability-challenge-contract","experimental/alt-da.html#parameters","experimental/alt-da.html#derivation","experimental/alt-da.html#fault-proof","experimental/alt-da.html#l2-input","experimental/alt-da.html#l1-challenge-status","experimental/alt-da.html#safety-and-finality","experimental/alt-da.html#security-considerations","interop/overview.html#interop","interop/overview.html#specifications","interop/dependency-set.html#the-dependency-set","interop/dependency-set.html#chain-id","interop/dependency-set.html#updating-the-dependency-set","interop/dependency-set.html#security-considerations","interop/dependency-set.html#layer-1-as-part-of-the-dependency-set","interop/messaging.html#messaging","interop/messaging.html#message","interop/messaging.html#message-payload","interop/messaging.html#message-identifier","interop/messaging.html#messaging-ends","interop/messaging.html#initiating-messages","interop/messaging.html#executing-messages","interop/messaging.html#messaging-invariants","interop/messaging.html#timestamp-invariant","interop/messaging.html#chainid-invariant","interop/messaging.html#message-expiry-invariant","interop/messaging.html#message-graph","interop/messaging.html#invalid-messages","interop/messaging.html#intra-block-messaging-cycles","interop/messaging.html#resolving-cross-chain-safety","interop/messaging.html#horizon-timestamp","interop/messaging.html#pruning-the-graph","interop/messaging.html#bounding-the-graph","interop/messaging.html#security-considerations","interop/messaging.html#cyclic-dependencies","interop/messaging.html#transitive-dependencies","interop/predeploys.html#predeploys","interop/predeploys.html#crossl2inbox","interop/predeploys.html#functions","interop/predeploys.html#interop-start-timestamp","interop/predeploys.html#executingmessage-event","interop/predeploys.html#reference-implementation","interop/predeploys.html#deposit-handling","interop/predeploys.html#identifier-getters","interop/predeploys.html#l2tol2crossdomainmessenger","interop/predeploys.html#relaymessage-invariants","interop/predeploys.html#sendexpire-invariants","interop/predeploys.html#relayexpire-invariants","interop/predeploys.html#message-versioning","interop/predeploys.html#no-native-support-for-cross-chain-ether-sends","interop/predeploys.html#interfaces","interop/predeploys.html#optimismsuperchainerc20factory","interop/predeploys.html#optimismsuperchainerc20","interop/predeploys.html#overview","interop/predeploys.html#functions-1","interop/predeploys.html#events","interop/predeploys.html#deployment-flow","interop/predeploys.html#beaconcontract","interop/predeploys.html#overview-1","interop/predeploys.html#l1block","interop/predeploys.html#static-configuration","interop/predeploys.html#dependency-set","interop/predeploys.html#deposit-context","interop/predeploys.html#isdeposit","interop/predeploys.html#optimismmintableerc20factory","interop/predeploys.html#optimismmintableerc20","interop/predeploys.html#updates","interop/predeploys.html#functions-2","interop/predeploys.html#events-1","interop/predeploys.html#l2standardbridge","interop/predeploys.html#updates-1","interop/predeploys.html#invariants","interop/predeploys.html#conversion-flow","interop/predeploys.html#superchainerc20bridge","interop/predeploys.html#overview-2","interop/predeploys.html#functions-3","interop/predeploys.html#events-2","interop/predeploys.html#diagram","interop/predeploys.html#invariants-1","interop/predeploys.html#security-considerations","interop/sequencer.html#sequencer","interop/sequencer.html#sequencer-policy","interop/sequencer.html#block-building","interop/sequencer.html#static-analysis","interop/sequencer.html#dependency-confirmations","interop/sequencer.html#sponsorship","interop/sequencer.html#security-considerations","interop/sequencer.html#cross-chain-message-latency","interop/verifier.html#verifier","interop/verifier.html#derivation-pipeline","interop/verifier.html#depositing-an-executing-message","interop/verifier.html#safety","interop/verifier.html#honest-verifier","interop/verifier.html#security-considerations","interop/verifier.html#forced-inclusion-of-cross-chain-messages","interop/verifier.html#reliance-on-history","interop/rollup-node-p2p.html#p2p-networking","interop/rollup-node-p2p.html#security-considerations","interop/fault-proof.html#fault-proof","interop/fault-proof.html#cascading-dependencies","interop/fault-proof.html#security-considerations","interop/upgrade.html#interop-network-upgrade","interop/upgrade.html#l1-attributes","interop/upgrade.html#l1-attributes-predeployed-contract","interop/upgrade.html#interop-l1block-upgrade","interop/upgrade.html#security-considerations","interop/token-bridging.html#token-bridging","interop/token-bridging.html#overview","interop/token-bridging.html#superchainerc20-standard","interop/token-bridging.html#properties","interop/token-bridging.html#interface","interop/token-bridging.html#superchainerc20bridge","interop/token-bridging.html#diagram","interop/token-bridging.html#implementation","interop/token-bridging.html#future-considerations","interop/token-bridging.html#cross-chain-transferfrom","interop/token-bridging.html#concatenated-action","interop/superchain-weth.html#superchain-weth","interop/superchain-weth.html#motivation-and-constraints","interop/superchain-weth.html#handling-native-assets-other-than-eth","interop/superchain-weth.html#minimizing-protocol-complexity","interop/superchain-weth.html#constants","interop/superchain-weth.html#superchainweth","interop/superchain-weth.html#invariants","interop/superchain-weth.html#ethliquidity","interop/superchain-weth.html#invariants-1","interop/derivation.html#derivation","interop/derivation.html#overview","interop/derivation.html#deposit-context","interop/derivation.html#security-considerations","interop/derivation.html#gas-considerations","interop/tx-pool.html#transaction-pool","interop/tx-pool.html#message-validation","interop/tx-pool.html#system-deposits-transaction-margin","interop/tx-pool.html#security-considerations","interop/tx-pool.html#mempool-denial-of-service","experimental/op-contracts-manager.html#op-contracts-manager","experimental/op-contracts-manager.html#deployment","experimental/op-contracts-manager.html#interface","experimental/op-contracts-manager.html#proxysol","experimental/op-contracts-manager.html#deploy","experimental/op-contracts-manager.html#getter-methods","experimental/op-contracts-manager.html#implementation","experimental/op-contracts-manager.html#batch-inbox-address","experimental/op-contracts-manager.html#contract-deployments","experimental/op-contracts-manager.html#security-considerations","experimental/op-contracts-manager.html#chain-id-source-of-truth","experimental/op-contracts-manager.html#chain-id-frontrunning","experimental/op-contracts-manager.html#chain-id-value","experimental/op-contracts-manager.html#proxy-admin-owner","experimental/op-contracts-manager.html#upgradeability-abi-changes","experimental/gov-token.html#governance-token","experimental/gov-token.html#overview","experimental/gov-token.html#hook-based-integration-with-governancedelegation","experimental/gov-token.html#token-minting","experimental/gov-token.html#token-burning","experimental/gov-token.html#voting-power","experimental/gov-token.html#delegation","glossary.html#glossary","glossary.html#general-terms","glossary.html#layer-1-l1","glossary.html#layer-2-l2","glossary.html#block","glossary.html#eoa","glossary.html#merkle-patricia-trie","glossary.html#chain-re-organization","glossary.html#predeployed-contract-predeploy","glossary.html#preinstalled-contract-preinstall","glossary.html#precompiled-contract-precompile","glossary.html#receipt","glossary.html#transaction-type","glossary.html#fork-choice-rule","glossary.html#priority-gas-auction","glossary.html#sequencing","glossary.html#sequencer","glossary.html#sequencing-window","glossary.html#sequencing-epoch","glossary.html#l1-origin","glossary.html#deposits","glossary.html#deposited-transaction","glossary.html#l1-attributes-deposited-transaction","glossary.html#user-deposited-transaction","glossary.html#depositing-call","glossary.html#depositing-transaction","glossary.html#depositor","glossary.html#deposited-transaction-type","glossary.html#deposit-contract","glossary.html#withdrawals","glossary.html#relayer","glossary.html#finalization-period","glossary.html#batch-submission","glossary.html#data-availability","glossary.html#data-availability-provider","glossary.html#sequencer-batch","glossary.html#channel","glossary.html#channel-frame","glossary.html#batcher","glossary.html#batcher-transaction","glossary.html#batch-submission-frequency","glossary.html#channel-timeout","glossary.html#l2-output-root-proposals","glossary.html#proposer","glossary.html#l2-chain-derivation","glossary.html#l2-derivation-inputs","glossary.html#system-configuration","glossary.html#payload-attributes","glossary.html#l2-genesis-block","glossary.html#l2-chain-inception","glossary.html#safe-l2-block","glossary.html#safe-l2-head","glossary.html#unsafe-l2-block","glossary.html#unsafe-l2-head","glossary.html#unsafe-block-consolidation","glossary.html#finalized-l2-head","glossary.html#other-l2-chain-concepts","glossary.html#address-aliasing","glossary.html#rollup-node","glossary.html#rollup-driver","glossary.html#l1-attributes-predeployed-contract","glossary.html#l2-output-root","glossary.html#l2-output-oracle-contract","glossary.html#validator","glossary.html#fault-proof","glossary.html#time-slot","glossary.html#block-time","glossary.html#unsafe-sync","glossary.html#execution-engine-concepts","glossary.html#execution-engine"],"index":{"documentStore":{"docInfo":{"0":{"body":7,"breadcrumbs":4,"title":3},"1":{"body":51,"breadcrumbs":2,"title":1},"10":{"body":17,"breadcrumbs":3,"title":2},"100":{"body":260,"breadcrumbs":7,"title":1},"101":{"body":81,"breadcrumbs":7,"title":1},"102":{"body":7,"breadcrumbs":7,"title":1},"103":{"body":30,"breadcrumbs":7,"title":1},"104":{"body":9,"breadcrumbs":7,"title":1},"105":{"body":36,"breadcrumbs":7,"title":1},"106":{"body":72,"breadcrumbs":7,"title":1},"107":{"body":99,"breadcrumbs":7,"title":1},"108":{"body":53,"breadcrumbs":7,"title":1},"109":{"body":99,"breadcrumbs":9,"title":3},"11":{"body":33,"breadcrumbs":2,"title":1},"110":{"body":47,"breadcrumbs":9,"title":3},"111":{"body":97,"breadcrumbs":10,"title":4},"112":{"body":80,"breadcrumbs":10,"title":4},"113":{"body":31,"breadcrumbs":8,"title":2},"114":{"body":20,"breadcrumbs":9,"title":3},"115":{"body":26,"breadcrumbs":7,"title":1},"116":{"body":26,"breadcrumbs":7,"title":1},"117":{"body":85,"breadcrumbs":7,"title":1},"118":{"body":13,"breadcrumbs":10,"title":4},"119":{"body":112,"breadcrumbs":7,"title":1},"12":{"body":30,"breadcrumbs":2,"title":1},"120":{"body":57,"breadcrumbs":9,"title":3},"121":{"body":61,"breadcrumbs":9,"title":3},"122":{"body":60,"breadcrumbs":13,"title":4},"123":{"body":143,"breadcrumbs":10,"title":1},"124":{"body":0,"breadcrumbs":11,"title":2},"125":{"body":69,"breadcrumbs":10,"title":1},"126":{"body":149,"breadcrumbs":10,"title":1},"127":{"body":576,"breadcrumbs":10,"title":1},"128":{"body":9,"breadcrumbs":11,"title":2},"129":{"body":5,"breadcrumbs":10,"title":1},"13":{"body":29,"breadcrumbs":2,"title":1},"130":{"body":4,"breadcrumbs":10,"title":1},"131":{"body":4,"breadcrumbs":10,"title":1},"132":{"body":71,"breadcrumbs":11,"title":2},"133":{"body":42,"breadcrumbs":11,"title":2},"134":{"body":233,"breadcrumbs":11,"title":2},"135":{"body":167,"breadcrumbs":11,"title":2},"136":{"body":255,"breadcrumbs":10,"title":1},"137":{"body":130,"breadcrumbs":11,"title":4},"138":{"body":420,"breadcrumbs":8,"title":1},"139":{"body":59,"breadcrumbs":10,"title":3},"14":{"body":84,"breadcrumbs":3,"title":2},"140":{"body":49,"breadcrumbs":9,"title":2},"141":{"body":0,"breadcrumbs":9,"title":2},"142":{"body":147,"breadcrumbs":11,"title":4},"143":{"body":478,"breadcrumbs":11,"title":4},"144":{"body":64,"breadcrumbs":10,"title":3},"145":{"body":115,"breadcrumbs":9,"title":2},"146":{"body":133,"breadcrumbs":9,"title":2},"147":{"body":120,"breadcrumbs":9,"title":2},"148":{"body":33,"breadcrumbs":8,"title":1},"149":{"body":143,"breadcrumbs":11,"title":4},"15":{"body":18,"breadcrumbs":2,"title":1},"150":{"body":47,"breadcrumbs":9,"title":2},"151":{"body":68,"breadcrumbs":9,"title":2},"152":{"body":20,"breadcrumbs":9,"title":2},"153":{"body":311,"breadcrumbs":9,"title":2},"154":{"body":19,"breadcrumbs":11,"title":4},"155":{"body":480,"breadcrumbs":9,"title":2},"156":{"body":57,"breadcrumbs":10,"title":3},"157":{"body":874,"breadcrumbs":9,"title":2},"158":{"body":581,"breadcrumbs":9,"title":2},"159":{"body":43,"breadcrumbs":10,"title":3},"16":{"body":103,"breadcrumbs":2,"title":1},"160":{"body":140,"breadcrumbs":10,"title":3},"161":{"body":700,"breadcrumbs":11,"title":4},"162":{"body":65,"breadcrumbs":11,"title":4},"163":{"body":3,"breadcrumbs":8,"title":2},"164":{"body":116,"breadcrumbs":7,"title":1},"165":{"body":114,"breadcrumbs":7,"title":2},"166":{"body":77,"breadcrumbs":6,"title":1},"167":{"body":52,"breadcrumbs":8,"title":3},"168":{"body":548,"breadcrumbs":9,"title":4},"169":{"body":51,"breadcrumbs":6,"title":1},"17":{"body":62,"breadcrumbs":2,"title":1},"170":{"body":215,"breadcrumbs":6,"title":1},"171":{"body":128,"breadcrumbs":8,"title":3},"172":{"body":55,"breadcrumbs":8,"title":3},"173":{"body":146,"breadcrumbs":6,"title":1},"174":{"body":252,"breadcrumbs":7,"title":2},"175":{"body":142,"breadcrumbs":6,"title":1},"176":{"body":190,"breadcrumbs":9,"title":4},"177":{"body":55,"breadcrumbs":7,"title":2},"178":{"body":104,"breadcrumbs":8,"title":3},"179":{"body":88,"breadcrumbs":10,"title":5},"18":{"body":0,"breadcrumbs":4,"title":3},"180":{"body":30,"breadcrumbs":14,"title":5},"181":{"body":75,"breadcrumbs":10,"title":1},"182":{"body":116,"breadcrumbs":10,"title":1},"183":{"body":51,"breadcrumbs":11,"title":2},"184":{"body":59,"breadcrumbs":10,"title":1},"185":{"body":82,"breadcrumbs":10,"title":1},"186":{"body":63,"breadcrumbs":11,"title":2},"187":{"body":165,"breadcrumbs":10,"title":1},"188":{"body":126,"breadcrumbs":10,"title":1},"189":{"body":26,"breadcrumbs":11,"title":2},"19":{"body":93,"breadcrumbs":4,"title":3},"190":{"body":22,"breadcrumbs":11,"title":2},"191":{"body":162,"breadcrumbs":12,"title":3},"192":{"body":68,"breadcrumbs":10,"title":1},"193":{"body":0,"breadcrumbs":11,"title":2},"194":{"body":147,"breadcrumbs":11,"title":2},"195":{"body":121,"breadcrumbs":11,"title":2},"196":{"body":19,"breadcrumbs":11,"title":3},"197":{"body":8,"breadcrumbs":14,"title":3},"198":{"body":74,"breadcrumbs":12,"title":1},"199":{"body":179,"breadcrumbs":12,"title":1},"2":{"body":28,"breadcrumbs":3,"title":2},"20":{"body":141,"breadcrumbs":2,"title":1},"200":{"body":614,"breadcrumbs":13,"title":2},"201":{"body":348,"breadcrumbs":13,"title":2},"202":{"body":52,"breadcrumbs":14,"title":3},"203":{"body":79,"breadcrumbs":12,"title":1},"204":{"body":0,"breadcrumbs":12,"title":1},"205":{"body":44,"breadcrumbs":14,"title":3},"206":{"body":31,"breadcrumbs":12,"title":1},"207":{"body":25,"breadcrumbs":13,"title":2},"208":{"body":64,"breadcrumbs":12,"title":1},"209":{"body":78,"breadcrumbs":13,"title":2},"21":{"body":19,"breadcrumbs":3,"title":2},"210":{"body":29,"breadcrumbs":14,"title":3},"211":{"body":34,"breadcrumbs":12,"title":1},"212":{"body":80,"breadcrumbs":12,"title":1},"213":{"body":68,"breadcrumbs":13,"title":2},"214":{"body":112,"breadcrumbs":12,"title":1},"215":{"body":12,"breadcrumbs":12,"title":1},"216":{"body":15,"breadcrumbs":12,"title":1},"217":{"body":92,"breadcrumbs":13,"title":2},"218":{"body":22,"breadcrumbs":14,"title":3},"219":{"body":32,"breadcrumbs":12,"title":1},"22":{"body":72,"breadcrumbs":5,"title":2},"220":{"body":216,"breadcrumbs":12,"title":1},"221":{"body":110,"breadcrumbs":15,"title":4},"222":{"body":122,"breadcrumbs":12,"title":1},"223":{"body":123,"breadcrumbs":13,"title":2},"224":{"body":428,"breadcrumbs":13,"title":2},"225":{"body":58,"breadcrumbs":13,"title":2},"226":{"body":128,"breadcrumbs":13,"title":2},"227":{"body":229,"breadcrumbs":12,"title":1},"228":{"body":87,"breadcrumbs":12,"title":1},"229":{"body":12,"breadcrumbs":18,"title":5},"23":{"body":98,"breadcrumbs":6,"title":3},"230":{"body":90,"breadcrumbs":14,"title":1},"231":{"body":39,"breadcrumbs":14,"title":1},"232":{"body":93,"breadcrumbs":17,"title":4},"233":{"body":52,"breadcrumbs":14,"title":1},"234":{"body":65,"breadcrumbs":14,"title":1},"235":{"body":11,"breadcrumbs":14,"title":1},"236":{"body":64,"breadcrumbs":14,"title":1},"237":{"body":31,"breadcrumbs":15,"title":2},"238":{"body":65,"breadcrumbs":14,"title":1},"239":{"body":60,"breadcrumbs":14,"title":1},"24":{"body":0,"breadcrumbs":5,"title":2},"240":{"body":42,"breadcrumbs":15,"title":2},"241":{"body":53,"breadcrumbs":16,"title":3},"242":{"body":15,"breadcrumbs":17,"title":4},"243":{"body":27,"breadcrumbs":15,"title":2},"244":{"body":37,"breadcrumbs":16,"title":3},"245":{"body":90,"breadcrumbs":15,"title":2},"246":{"body":23,"breadcrumbs":16,"title":3},"247":{"body":31,"breadcrumbs":14,"title":1},"248":{"body":367,"breadcrumbs":14,"title":1},"249":{"body":54,"breadcrumbs":12,"title":2},"25":{"body":394,"breadcrumbs":7,"title":4},"250":{"body":27,"breadcrumbs":11,"title":1},"251":{"body":151,"breadcrumbs":12,"title":2},"252":{"body":0,"breadcrumbs":14,"title":4},"253":{"body":10,"breadcrumbs":12,"title":2},"254":{"body":39,"breadcrumbs":13,"title":3},"255":{"body":42,"breadcrumbs":12,"title":2},"256":{"body":96,"breadcrumbs":12,"title":2},"257":{"body":168,"breadcrumbs":12,"title":2},"258":{"body":122,"breadcrumbs":12,"title":2},"259":{"body":168,"breadcrumbs":12,"title":2},"26":{"body":251,"breadcrumbs":7,"title":4},"260":{"body":23,"breadcrumbs":12,"title":2},"261":{"body":43,"breadcrumbs":12,"title":2},"262":{"body":12,"breadcrumbs":12,"title":2},"263":{"body":43,"breadcrumbs":11,"title":1},"264":{"body":4,"breadcrumbs":5,"title":1},"265":{"body":61,"breadcrumbs":5,"title":1},"266":{"body":35,"breadcrumbs":5,"title":1},"267":{"body":24,"breadcrumbs":5,"title":1},"268":{"body":168,"breadcrumbs":5,"title":1},"269":{"body":71,"breadcrumbs":5,"title":1},"27":{"body":70,"breadcrumbs":6,"title":3},"270":{"body":33,"breadcrumbs":5,"title":1},"271":{"body":48,"breadcrumbs":5,"title":1},"272":{"body":41,"breadcrumbs":5,"title":1},"273":{"body":19,"breadcrumbs":5,"title":1},"274":{"body":59,"breadcrumbs":5,"title":1},"275":{"body":84,"breadcrumbs":5,"title":1},"276":{"body":30,"breadcrumbs":5,"title":1},"277":{"body":141,"breadcrumbs":5,"title":1},"278":{"body":16,"breadcrumbs":5,"title":1},"279":{"body":18,"breadcrumbs":5,"title":1},"28":{"body":142,"breadcrumbs":6,"title":3},"280":{"body":29,"breadcrumbs":5,"title":1},"281":{"body":43,"breadcrumbs":5,"title":1},"282":{"body":14,"breadcrumbs":5,"title":1},"283":{"body":25,"breadcrumbs":5,"title":1},"284":{"body":21,"breadcrumbs":5,"title":1},"285":{"body":13,"breadcrumbs":5,"title":1},"286":{"body":10,"breadcrumbs":5,"title":1},"287":{"body":18,"breadcrumbs":7,"title":3},"288":{"body":32,"breadcrumbs":5,"title":1},"289":{"body":96,"breadcrumbs":5,"title":1},"29":{"body":56,"breadcrumbs":5,"title":2},"290":{"body":18,"breadcrumbs":5,"title":1},"291":{"body":16,"breadcrumbs":5,"title":1},"292":{"body":8,"breadcrumbs":5,"title":1},"293":{"body":9,"breadcrumbs":5,"title":1},"294":{"body":51,"breadcrumbs":5,"title":1},"295":{"body":24,"breadcrumbs":5,"title":1},"296":{"body":127,"breadcrumbs":5,"title":1},"297":{"body":26,"breadcrumbs":5,"title":1},"298":{"body":87,"breadcrumbs":8,"title":4},"299":{"body":22,"breadcrumbs":5,"title":1},"3":{"body":17,"breadcrumbs":3,"title":2},"30":{"body":0,"breadcrumbs":6,"title":3},"300":{"body":12,"breadcrumbs":8,"title":4},"301":{"body":14,"breadcrumbs":8,"title":4},"302":{"body":12,"breadcrumbs":8,"title":4},"303":{"body":14,"breadcrumbs":8,"title":4},"304":{"body":13,"breadcrumbs":8,"title":2},"305":{"body":14,"breadcrumbs":7,"title":1},"306":{"body":25,"breadcrumbs":8,"title":2},"307":{"body":29,"breadcrumbs":9,"title":3},"308":{"body":70,"breadcrumbs":7,"title":1},"309":{"body":52,"breadcrumbs":8,"title":2},"31":{"body":69,"breadcrumbs":4,"title":1},"310":{"body":57,"breadcrumbs":7,"title":1},"311":{"body":123,"breadcrumbs":8,"title":2},"312":{"body":326,"breadcrumbs":9,"title":3},"313":{"body":36,"breadcrumbs":9,"title":3},"314":{"body":42,"breadcrumbs":8,"title":2},"315":{"body":88,"breadcrumbs":9,"title":3},"316":{"body":47,"breadcrumbs":9,"title":3},"317":{"body":58,"breadcrumbs":8,"title":2},"318":{"body":72,"breadcrumbs":12,"title":6},"319":{"body":100,"breadcrumbs":11,"title":5},"32":{"body":326,"breadcrumbs":5,"title":2},"320":{"body":130,"breadcrumbs":10,"title":4},"321":{"body":0,"breadcrumbs":10,"title":4},"322":{"body":49,"breadcrumbs":8,"title":2},"323":{"body":31,"breadcrumbs":7,"title":2},"324":{"body":19,"breadcrumbs":6,"title":1},"325":{"body":8,"breadcrumbs":10,"title":5},"326":{"body":43,"breadcrumbs":7,"title":2},"327":{"body":287,"breadcrumbs":6,"title":1},"328":{"body":51,"breadcrumbs":7,"title":2},"329":{"body":51,"breadcrumbs":7,"title":2},"33":{"body":139,"breadcrumbs":5,"title":2},"330":{"body":33,"breadcrumbs":8,"title":3},"331":{"body":219,"breadcrumbs":8,"title":3},"332":{"body":256,"breadcrumbs":7,"title":3},"333":{"body":0,"breadcrumbs":6,"title":2},"334":{"body":26,"breadcrumbs":7,"title":3},"335":{"body":22,"breadcrumbs":6,"title":2},"336":{"body":29,"breadcrumbs":6,"title":2},"337":{"body":41,"breadcrumbs":7,"title":3},"338":{"body":34,"breadcrumbs":7,"title":3},"339":{"body":31,"breadcrumbs":7,"title":3},"34":{"body":6,"breadcrumbs":6,"title":2},"340":{"body":25,"breadcrumbs":8,"title":4},"341":{"body":32,"breadcrumbs":8,"title":4},"342":{"body":26,"breadcrumbs":8,"title":4},"343":{"body":27,"breadcrumbs":7,"title":3},"344":{"body":27,"breadcrumbs":7,"title":3},"345":{"body":36,"breadcrumbs":9,"title":5},"346":{"body":28,"breadcrumbs":9,"title":5},"347":{"body":34,"breadcrumbs":8,"title":4},"348":{"body":30,"breadcrumbs":8,"title":4},"349":{"body":18,"breadcrumbs":9,"title":5},"35":{"body":186,"breadcrumbs":5,"title":1},"350":{"body":20,"breadcrumbs":6,"title":2},"351":{"body":31,"breadcrumbs":6,"title":2},"352":{"body":29,"breadcrumbs":6,"title":2},"353":{"body":24,"breadcrumbs":7,"title":3},"354":{"body":26,"breadcrumbs":6,"title":2},"355":{"body":48,"breadcrumbs":7,"title":3},"356":{"body":19,"breadcrumbs":6,"title":2},"357":{"body":35,"breadcrumbs":6,"title":2},"358":{"body":23,"breadcrumbs":6,"title":2},"359":{"body":18,"breadcrumbs":6,"title":2},"36":{"body":24,"breadcrumbs":6,"title":2},"360":{"body":0,"breadcrumbs":6,"title":2},"361":{"body":34,"breadcrumbs":7,"title":3},"362":{"body":48,"breadcrumbs":7,"title":3},"363":{"body":39,"breadcrumbs":6,"title":2},"364":{"body":0,"breadcrumbs":6,"title":2},"365":{"body":52,"breadcrumbs":7,"title":3},"366":{"body":20,"breadcrumbs":7,"title":3},"367":{"body":31,"breadcrumbs":7,"title":3},"368":{"body":37,"breadcrumbs":7,"title":3},"369":{"body":83,"breadcrumbs":7,"title":3},"37":{"body":8,"breadcrumbs":5,"title":1},"370":{"body":0,"breadcrumbs":6,"title":2},"371":{"body":15,"breadcrumbs":7,"title":3},"372":{"body":33,"breadcrumbs":6,"title":2},"373":{"body":37,"breadcrumbs":6,"title":2},"374":{"body":39,"breadcrumbs":6,"title":2},"375":{"body":28,"breadcrumbs":9,"title":5},"376":{"body":128,"breadcrumbs":8,"title":3},"377":{"body":6,"breadcrumbs":7,"title":2},"378":{"body":178,"breadcrumbs":8,"title":3},"379":{"body":58,"breadcrumbs":10,"title":5},"38":{"body":17,"breadcrumbs":8,"title":3},"380":{"body":52,"breadcrumbs":10,"title":5},"381":{"body":94,"breadcrumbs":7,"title":2},"382":{"body":52,"breadcrumbs":7,"title":2},"383":{"body":51,"breadcrumbs":9,"title":4},"384":{"body":23,"breadcrumbs":6,"title":1},"385":{"body":126,"breadcrumbs":8,"title":3},"386":{"body":29,"breadcrumbs":11,"title":6},"387":{"body":0,"breadcrumbs":7,"title":2},"388":{"body":22,"breadcrumbs":10,"title":5},"389":{"body":62,"breadcrumbs":9,"title":4},"39":{"body":186,"breadcrumbs":6,"title":1},"390":{"body":76,"breadcrumbs":9,"title":4},"391":{"body":14,"breadcrumbs":13,"title":4},"392":{"body":20,"breadcrumbs":10,"title":1},"393":{"body":7,"breadcrumbs":12,"title":3},"394":{"body":82,"breadcrumbs":12,"title":3},"395":{"body":177,"breadcrumbs":11,"title":2},"396":{"body":134,"breadcrumbs":12,"title":3},"397":{"body":3,"breadcrumbs":7,"title":1},"398":{"body":158,"breadcrumbs":7,"title":1},"399":{"body":40,"breadcrumbs":7,"title":1},"4":{"body":29,"breadcrumbs":2,"title":1},"40":{"body":75,"breadcrumbs":7,"title":2},"400":{"body":51,"breadcrumbs":8,"title":2},"401":{"body":3,"breadcrumbs":8,"title":2},"402":{"body":16,"breadcrumbs":7,"title":1},"403":{"body":9,"breadcrumbs":8,"title":2},"404":{"body":70,"breadcrumbs":10,"title":2},"405":{"body":150,"breadcrumbs":9,"title":1},"406":{"body":314,"breadcrumbs":11,"title":3},"407":{"body":38,"breadcrumbs":12,"title":4},"408":{"body":74,"breadcrumbs":12,"title":4},"409":{"body":41,"breadcrumbs":12,"title":4},"41":{"body":13,"breadcrumbs":6,"title":1},"410":{"body":0,"breadcrumbs":10,"title":2},"411":{"body":27,"breadcrumbs":13,"title":5},"412":{"body":19,"breadcrumbs":12,"title":4},"413":{"body":20,"breadcrumbs":13,"title":5},"414":{"body":24,"breadcrumbs":13,"title":5},"415":{"body":44,"breadcrumbs":13,"title":5},"416":{"body":64,"breadcrumbs":13,"title":5},"417":{"body":32,"breadcrumbs":14,"title":6},"418":{"body":75,"breadcrumbs":11,"title":3},"419":{"body":142,"breadcrumbs":12,"title":4},"42":{"body":36,"breadcrumbs":7,"title":2},"420":{"body":0,"breadcrumbs":9,"title":1},"421":{"body":18,"breadcrumbs":12,"title":4},"422":{"body":482,"breadcrumbs":10,"title":2},"423":{"body":101,"breadcrumbs":9,"title":1},"424":{"body":18,"breadcrumbs":9,"title":3},"425":{"body":80,"breadcrumbs":8,"title":2},"426":{"body":30,"breadcrumbs":8,"title":2},"427":{"body":7,"breadcrumbs":8,"title":1},"428":{"body":110,"breadcrumbs":10,"title":3},"429":{"body":279,"breadcrumbs":9,"title":2},"43":{"body":6,"breadcrumbs":8,"title":3},"430":{"body":10,"breadcrumbs":11,"title":3},"431":{"body":203,"breadcrumbs":9,"title":1},"432":{"body":116,"breadcrumbs":12,"title":4},"433":{"body":111,"breadcrumbs":11,"title":3},"434":{"body":6,"breadcrumbs":9,"title":3},"435":{"body":22,"breadcrumbs":8,"title":2},"436":{"body":16,"breadcrumbs":8,"title":2},"437":{"body":27,"breadcrumbs":11,"title":3},"438":{"body":0,"breadcrumbs":9,"title":1},"439":{"body":266,"breadcrumbs":14,"title":6},"44":{"body":8,"breadcrumbs":8,"title":3},"440":{"body":24,"breadcrumbs":12,"title":4},"441":{"body":35,"breadcrumbs":12,"title":5},"442":{"body":35,"breadcrumbs":10,"title":3},"443":{"body":51,"breadcrumbs":9,"title":2},"444":{"body":34,"breadcrumbs":11,"title":4},"445":{"body":53,"breadcrumbs":8,"title":1},"446":{"body":66,"breadcrumbs":9,"title":2},"447":{"body":57,"breadcrumbs":10,"title":3},"448":{"body":110,"breadcrumbs":8,"title":1},"449":{"body":115,"breadcrumbs":9,"title":2},"45":{"body":45,"breadcrumbs":8,"title":3},"450":{"body":75,"breadcrumbs":10,"title":3},"451":{"body":43,"breadcrumbs":11,"title":4},"452":{"body":106,"breadcrumbs":9,"title":2},"453":{"body":75,"breadcrumbs":10,"title":3},"454":{"body":66,"breadcrumbs":10,"title":3},"455":{"body":7,"breadcrumbs":8,"title":1},"456":{"body":130,"breadcrumbs":8,"title":1},"457":{"body":91,"breadcrumbs":11,"title":4},"458":{"body":6,"breadcrumbs":9,"title":3},"459":{"body":5,"breadcrumbs":8,"title":2},"46":{"body":64,"breadcrumbs":6,"title":1},"460":{"body":4,"breadcrumbs":8,"title":2},"461":{"body":8,"breadcrumbs":11,"title":3},"462":{"body":0,"breadcrumbs":10,"title":2},"463":{"body":25,"breadcrumbs":12,"title":4},"464":{"body":8,"breadcrumbs":12,"title":5},"465":{"body":20,"breadcrumbs":10,"title":3},"466":{"body":18,"breadcrumbs":10,"title":3},"467":{"body":12,"breadcrumbs":9,"title":3},"468":{"body":4,"breadcrumbs":8,"title":2},"469":{"body":2,"breadcrumbs":8,"title":2},"47":{"body":40,"breadcrumbs":6,"title":1},"470":{"body":2,"breadcrumbs":8,"title":2},"471":{"body":52,"breadcrumbs":12,"title":5},"472":{"body":0,"breadcrumbs":9,"title":2},"473":{"body":114,"breadcrumbs":8,"title":1},"474":{"body":174,"breadcrumbs":9,"title":2},"475":{"body":13,"breadcrumbs":9,"title":2},"476":{"body":32,"breadcrumbs":8,"title":1},"477":{"body":6,"breadcrumbs":8,"title":1},"478":{"body":77,"breadcrumbs":10,"title":3},"479":{"body":167,"breadcrumbs":9,"title":2},"48":{"body":205,"breadcrumbs":8,"title":3},"480":{"body":83,"breadcrumbs":9,"title":2},"481":{"body":39,"breadcrumbs":10,"title":3},"482":{"body":40,"breadcrumbs":9,"title":2},"483":{"body":72,"breadcrumbs":9,"title":2},"484":{"body":102,"breadcrumbs":8,"title":1},"485":{"body":0,"breadcrumbs":8,"title":1},"486":{"body":65,"breadcrumbs":11,"title":4},"487":{"body":59,"breadcrumbs":11,"title":4},"488":{"body":38,"breadcrumbs":10,"title":3},"489":{"body":54,"breadcrumbs":10,"title":3},"49":{"body":114,"breadcrumbs":8,"title":3},"490":{"body":70,"breadcrumbs":10,"title":3},"491":{"body":0,"breadcrumbs":10,"title":3},"492":{"body":85,"breadcrumbs":8,"title":1},"493":{"body":186,"breadcrumbs":9,"title":2},"494":{"body":180,"breadcrumbs":9,"title":2},"495":{"body":34,"breadcrumbs":11,"title":3},"496":{"body":15,"breadcrumbs":10,"title":2},"497":{"body":30,"breadcrumbs":12,"title":4},"498":{"body":40,"breadcrumbs":11,"title":3},"499":{"body":155,"breadcrumbs":11,"title":3},"5":{"body":40,"breadcrumbs":2,"title":1},"50":{"body":57,"breadcrumbs":8,"title":3},"500":{"body":33,"breadcrumbs":10,"title":2},"501":{"body":16,"breadcrumbs":10,"title":2},"502":{"body":45,"breadcrumbs":9,"title":1},"503":{"body":31,"breadcrumbs":9,"title":1},"504":{"body":13,"breadcrumbs":10,"title":2},"505":{"body":23,"breadcrumbs":11,"title":3},"506":{"body":6,"breadcrumbs":9,"title":1},"507":{"body":53,"breadcrumbs":9,"title":1},"508":{"body":53,"breadcrumbs":8,"title":1},"509":{"body":89,"breadcrumbs":8,"title":1},"51":{"body":24,"breadcrumbs":9,"title":4},"510":{"body":65,"breadcrumbs":8,"title":1},"511":{"body":149,"breadcrumbs":8,"title":1},"512":{"body":37,"breadcrumbs":8,"title":1},"513":{"body":11,"breadcrumbs":8,"title":1},"514":{"body":11,"breadcrumbs":8,"title":1},"515":{"body":11,"breadcrumbs":8,"title":1},"516":{"body":11,"breadcrumbs":8,"title":1},"517":{"body":0,"breadcrumbs":9,"title":2},"518":{"body":9,"breadcrumbs":8,"title":1},"519":{"body":28,"breadcrumbs":8,"title":1},"52":{"body":370,"breadcrumbs":6,"title":1},"520":{"body":7,"breadcrumbs":8,"title":1},"521":{"body":0,"breadcrumbs":8,"title":1},"522":{"body":58,"breadcrumbs":8,"title":1},"523":{"body":0,"breadcrumbs":8,"title":1},"524":{"body":56,"breadcrumbs":8,"title":1},"525":{"body":28,"breadcrumbs":8,"title":1},"526":{"body":15,"breadcrumbs":11,"title":4},"527":{"body":84,"breadcrumbs":8,"title":1},"528":{"body":7,"breadcrumbs":8,"title":1},"529":{"body":53,"breadcrumbs":8,"title":1},"53":{"body":146,"breadcrumbs":7,"title":2},"530":{"body":15,"breadcrumbs":5,"title":2},"531":{"body":49,"breadcrumbs":4,"title":1},"532":{"body":26,"breadcrumbs":5,"title":2},"533":{"body":25,"breadcrumbs":5,"title":2},"534":{"body":94,"breadcrumbs":5,"title":2},"535":{"body":37,"breadcrumbs":4,"title":1},"536":{"body":73,"breadcrumbs":7,"title":3},"537":{"body":83,"breadcrumbs":5,"title":1},"538":{"body":50,"breadcrumbs":5,"title":1},"539":{"body":77,"breadcrumbs":8,"title":4},"54":{"body":70,"breadcrumbs":9,"title":4},"540":{"body":50,"breadcrumbs":6,"title":2},"541":{"body":146,"breadcrumbs":8,"title":4},"542":{"body":0,"breadcrumbs":6,"title":2},"543":{"body":80,"breadcrumbs":6,"title":2},"544":{"body":20,"breadcrumbs":7,"title":3},"545":{"body":188,"breadcrumbs":5,"title":1},"546":{"body":65,"breadcrumbs":5,"title":1},"547":{"body":90,"breadcrumbs":5,"title":1},"548":{"body":85,"breadcrumbs":5,"title":1},"549":{"body":54,"breadcrumbs":5,"title":1},"55":{"body":25,"breadcrumbs":10,"title":5},"550":{"body":23,"breadcrumbs":5,"title":1},"551":{"body":39,"breadcrumbs":6,"title":2},"552":{"body":72,"breadcrumbs":7,"title":3},"553":{"body":86,"breadcrumbs":8,"title":4},"554":{"body":26,"breadcrumbs":5,"title":1},"555":{"body":146,"breadcrumbs":5,"title":1},"556":{"body":12,"breadcrumbs":6,"title":2},"557":{"body":12,"breadcrumbs":6,"title":2},"558":{"body":12,"breadcrumbs":6,"title":2},"559":{"body":12,"breadcrumbs":7,"title":3},"56":{"body":17,"breadcrumbs":8,"title":3},"560":{"body":12,"breadcrumbs":7,"title":3},"561":{"body":12,"breadcrumbs":7,"title":3},"562":{"body":17,"breadcrumbs":6,"title":2},"563":{"body":16,"breadcrumbs":6,"title":2},"564":{"body":47,"breadcrumbs":5,"title":1},"565":{"body":0,"breadcrumbs":6,"title":2},"566":{"body":25,"breadcrumbs":7,"title":3},"567":{"body":37,"breadcrumbs":6,"title":2},"568":{"body":17,"breadcrumbs":6,"title":2},"569":{"body":48,"breadcrumbs":6,"title":3},"57":{"body":19,"breadcrumbs":9,"title":4},"570":{"body":73,"breadcrumbs":4,"title":1},"571":{"body":194,"breadcrumbs":6,"title":3},"572":{"body":113,"breadcrumbs":5,"title":2},"573":{"body":0,"breadcrumbs":7,"title":4},"574":{"body":356,"breadcrumbs":4,"title":1},"575":{"body":393,"breadcrumbs":4,"title":1},"576":{"body":21,"breadcrumbs":5,"title":2},"577":{"body":7,"breadcrumbs":6,"title":3},"578":{"body":9,"breadcrumbs":8,"title":5},"579":{"body":125,"breadcrumbs":5,"title":2},"58":{"body":134,"breadcrumbs":9,"title":4},"580":{"body":63,"breadcrumbs":5,"title":2},"581":{"body":165,"breadcrumbs":3,"title":1},"582":{"body":78,"breadcrumbs":3,"title":1},"583":{"body":142,"breadcrumbs":6,"title":2},"584":{"body":69,"breadcrumbs":6,"title":2},"585":{"body":45,"breadcrumbs":7,"title":3},"586":{"body":0,"breadcrumbs":6,"title":2},"587":{"body":46,"breadcrumbs":9,"title":5},"588":{"body":50,"breadcrumbs":4,"title":1},"589":{"body":6,"breadcrumbs":4,"title":1},"59":{"body":92,"breadcrumbs":8,"title":3},"590":{"body":37,"breadcrumbs":5,"title":2},"591":{"body":121,"breadcrumbs":5,"title":2},"592":{"body":0,"breadcrumbs":5,"title":2},"593":{"body":43,"breadcrumbs":5,"title":2},"594":{"body":77,"breadcrumbs":5,"title":2},"595":{"body":41,"breadcrumbs":5,"title":2},"596":{"body":30,"breadcrumbs":5,"title":2},"597":{"body":21,"breadcrumbs":5,"title":2},"598":{"body":59,"breadcrumbs":6,"title":3},"599":{"body":25,"breadcrumbs":5,"title":2},"6":{"body":0,"breadcrumbs":2,"title":1},"60":{"body":121,"breadcrumbs":7,"title":2},"600":{"body":84,"breadcrumbs":5,"title":2},"601":{"body":28,"breadcrumbs":7,"title":4},"602":{"body":64,"breadcrumbs":7,"title":4},"603":{"body":15,"breadcrumbs":5,"title":2},"604":{"body":62,"breadcrumbs":5,"title":2},"605":{"body":67,"breadcrumbs":5,"title":2},"606":{"body":0,"breadcrumbs":5,"title":2},"607":{"body":27,"breadcrumbs":5,"title":2},"608":{"body":20,"breadcrumbs":5,"title":2},"609":{"body":118,"breadcrumbs":4,"title":1},"61":{"body":35,"breadcrumbs":6,"title":1},"610":{"body":25,"breadcrumbs":4,"title":1},"611":{"body":141,"breadcrumbs":4,"title":1},"612":{"body":67,"breadcrumbs":6,"title":3},"613":{"body":50,"breadcrumbs":5,"title":2},"614":{"body":175,"breadcrumbs":5,"title":2},"615":{"body":31,"breadcrumbs":5,"title":2},"616":{"body":11,"breadcrumbs":5,"title":2},"617":{"body":45,"breadcrumbs":4,"title":1},"618":{"body":9,"breadcrumbs":5,"title":2},"619":{"body":21,"breadcrumbs":5,"title":2},"62":{"body":132,"breadcrumbs":6,"title":1},"620":{"body":20,"breadcrumbs":5,"title":2},"621":{"body":17,"breadcrumbs":5,"title":2},"622":{"body":26,"breadcrumbs":9,"title":6},"623":{"body":464,"breadcrumbs":4,"title":1},"624":{"body":4,"breadcrumbs":4,"title":1},"625":{"body":31,"breadcrumbs":4,"title":1},"626":{"body":71,"breadcrumbs":4,"title":1},"627":{"body":85,"breadcrumbs":4,"title":1},"628":{"body":25,"breadcrumbs":4,"title":1},"629":{"body":49,"breadcrumbs":5,"title":2},"63":{"body":8,"breadcrumbs":7,"title":2},"630":{"body":4,"breadcrumbs":4,"title":1},"631":{"body":25,"breadcrumbs":4,"title":1},"632":{"body":6,"breadcrumbs":4,"title":1},"633":{"body":108,"breadcrumbs":5,"title":2},"634":{"body":113,"breadcrumbs":5,"title":2},"635":{"body":17,"breadcrumbs":5,"title":2},"636":{"body":34,"breadcrumbs":4,"title":1},"637":{"body":4,"breadcrumbs":4,"title":1},"638":{"body":34,"breadcrumbs":4,"title":1},"639":{"body":19,"breadcrumbs":4,"title":1},"64":{"body":17,"breadcrumbs":6,"title":1},"640":{"body":128,"breadcrumbs":4,"title":1},"641":{"body":34,"breadcrumbs":4,"title":1},"642":{"body":4,"breadcrumbs":4,"title":1},"643":{"body":110,"breadcrumbs":4,"title":1},"644":{"body":57,"breadcrumbs":4,"title":1},"645":{"body":53,"breadcrumbs":5,"title":2},"646":{"body":4,"breadcrumbs":4,"title":1},"647":{"body":19,"breadcrumbs":4,"title":1},"648":{"body":111,"breadcrumbs":4,"title":1},"649":{"body":40,"breadcrumbs":4,"title":1},"65":{"body":133,"breadcrumbs":6,"title":1},"650":{"body":83,"breadcrumbs":4,"title":1},"651":{"body":209,"breadcrumbs":4,"title":1},"652":{"body":1,"breadcrumbs":5,"title":2},"653":{"body":29,"breadcrumbs":4,"title":1},"654":{"body":39,"breadcrumbs":5,"title":2},"655":{"body":28,"breadcrumbs":5,"title":2},"656":{"body":21,"breadcrumbs":5,"title":2},"657":{"body":336,"breadcrumbs":5,"title":2},"658":{"body":25,"breadcrumbs":4,"title":1},"659":{"body":0,"breadcrumbs":5,"title":2},"66":{"body":81,"breadcrumbs":7,"title":2},"660":{"body":33,"breadcrumbs":7,"title":4},"661":{"body":31,"breadcrumbs":4,"title":1},"662":{"body":106,"breadcrumbs":5,"title":2},"663":{"body":78,"breadcrumbs":6,"title":3},"664":{"body":326,"breadcrumbs":4,"title":1},"665":{"body":26,"breadcrumbs":5,"title":2},"666":{"body":0,"breadcrumbs":5,"title":2},"667":{"body":113,"breadcrumbs":8,"title":5},"668":{"body":38,"breadcrumbs":5,"title":2},"669":{"body":58,"breadcrumbs":7,"title":2},"67":{"body":60,"breadcrumbs":8,"title":3},"670":{"body":1,"breadcrumbs":7,"title":2},"671":{"body":21,"breadcrumbs":6,"title":2},"672":{"body":36,"breadcrumbs":6,"title":2},"673":{"body":1,"breadcrumbs":6,"title":2},"674":{"body":102,"breadcrumbs":6,"title":3},"675":{"body":27,"breadcrumbs":5,"title":2},"676":{"body":36,"breadcrumbs":7,"title":4},"677":{"body":71,"breadcrumbs":6,"title":3},"678":{"body":1,"breadcrumbs":5,"title":2},"679":{"body":21,"breadcrumbs":6,"title":2},"68":{"body":54,"breadcrumbs":8,"title":3},"680":{"body":29,"breadcrumbs":5,"title":1},"681":{"body":0,"breadcrumbs":6,"title":2},"682":{"body":98,"breadcrumbs":5,"title":1},"683":{"body":54,"breadcrumbs":5,"title":1},"684":{"body":54,"breadcrumbs":5,"title":1},"685":{"body":83,"breadcrumbs":5,"title":1},"686":{"body":60,"breadcrumbs":5,"title":1},"687":{"body":0,"breadcrumbs":6,"title":2},"688":{"body":94,"breadcrumbs":7,"title":3},"689":{"body":156,"breadcrumbs":6,"title":2},"69":{"body":97,"breadcrumbs":8,"title":3},"690":{"body":58,"breadcrumbs":5,"title":2},"691":{"body":40,"breadcrumbs":5,"title":2},"692":{"body":53,"breadcrumbs":7,"title":4},"693":{"body":33,"breadcrumbs":6,"title":3},"694":{"body":8,"breadcrumbs":4,"title":1},"695":{"body":0,"breadcrumbs":4,"title":1},"696":{"body":105,"breadcrumbs":4,"title":1},"697":{"body":0,"breadcrumbs":4,"title":1},"698":{"body":136,"breadcrumbs":4,"title":1},"699":{"body":19,"breadcrumbs":4,"title":1},"7":{"body":47,"breadcrumbs":3,"title":2},"70":{"body":0,"breadcrumbs":7,"title":2},"700":{"body":0,"breadcrumbs":4,"title":1},"701":{"body":271,"breadcrumbs":5,"title":2},"702":{"body":0,"breadcrumbs":5,"title":2},"703":{"body":28,"breadcrumbs":5,"title":2},"704":{"body":76,"breadcrumbs":6,"title":2},"705":{"body":105,"breadcrumbs":6,"title":2},"706":{"body":70,"breadcrumbs":8,"title":4},"707":{"body":0,"breadcrumbs":6,"title":2},"708":{"body":43,"breadcrumbs":7,"title":3},"709":{"body":79,"breadcrumbs":7,"title":3},"71":{"body":79,"breadcrumbs":9,"title":4},"710":{"body":10,"breadcrumbs":5,"title":1},"711":{"body":10,"breadcrumbs":5,"title":1},"712":{"body":35,"breadcrumbs":5,"title":1},"713":{"body":106,"breadcrumbs":5,"title":1},"714":{"body":92,"breadcrumbs":6,"title":2},"715":{"body":0,"breadcrumbs":5,"title":1},"716":{"body":22,"breadcrumbs":7,"title":3},"717":{"body":98,"breadcrumbs":6,"title":2},"718":{"body":0,"breadcrumbs":6,"title":2},"719":{"body":92,"breadcrumbs":8,"title":4},"72":{"body":25,"breadcrumbs":11,"title":6},"720":{"body":30,"breadcrumbs":7,"title":3},"721":{"body":50,"breadcrumbs":7,"title":3},"722":{"body":22,"breadcrumbs":7,"title":3},"723":{"body":31,"breadcrumbs":7,"title":3},"724":{"body":15,"breadcrumbs":5,"title":2},"725":{"body":43,"breadcrumbs":4,"title":1},"726":{"body":147,"breadcrumbs":7,"title":4},"727":{"body":58,"breadcrumbs":5,"title":2},"728":{"body":27,"breadcrumbs":5,"title":2},"729":{"body":67,"breadcrumbs":5,"title":2},"73":{"body":63,"breadcrumbs":10,"title":5},"730":{"body":49,"breadcrumbs":4,"title":1},"731":{"body":161,"breadcrumbs":2,"title":1},"732":{"body":0,"breadcrumbs":3,"title":2},"733":{"body":9,"breadcrumbs":4,"title":3},"734":{"body":12,"breadcrumbs":4,"title":3},"735":{"body":62,"breadcrumbs":2,"title":1},"736":{"body":12,"breadcrumbs":2,"title":1},"737":{"body":34,"breadcrumbs":4,"title":3},"738":{"body":38,"breadcrumbs":4,"title":3},"739":{"body":13,"breadcrumbs":4,"title":3},"74":{"body":17,"breadcrumbs":11,"title":4},"740":{"body":27,"breadcrumbs":4,"title":3},"741":{"body":27,"breadcrumbs":4,"title":3},"742":{"body":45,"breadcrumbs":2,"title":1},"743":{"body":19,"breadcrumbs":3,"title":2},"744":{"body":34,"breadcrumbs":4,"title":3},"745":{"body":57,"breadcrumbs":4,"title":3},"746":{"body":33,"breadcrumbs":2,"title":1},"747":{"body":31,"breadcrumbs":2,"title":1},"748":{"body":50,"breadcrumbs":3,"title":2},"749":{"body":36,"breadcrumbs":3,"title":2},"75":{"body":122,"breadcrumbs":8,"title":1},"750":{"body":9,"breadcrumbs":3,"title":2},"751":{"body":80,"breadcrumbs":2,"title":1},"752":{"body":34,"breadcrumbs":3,"title":2},"753":{"body":41,"breadcrumbs":5,"title":4},"754":{"body":21,"breadcrumbs":4,"title":3},"755":{"body":20,"breadcrumbs":3,"title":2},"756":{"body":9,"breadcrumbs":3,"title":2},"757":{"body":15,"breadcrumbs":2,"title":1},"758":{"body":21,"breadcrumbs":4,"title":3},"759":{"body":46,"breadcrumbs":3,"title":2},"76":{"body":41,"breadcrumbs":9,"title":2},"760":{"body":53,"breadcrumbs":2,"title":1},"761":{"body":10,"breadcrumbs":2,"title":1},"762":{"body":30,"breadcrumbs":3,"title":2},"763":{"body":0,"breadcrumbs":3,"title":2},"764":{"body":48,"breadcrumbs":3,"title":2},"765":{"body":36,"breadcrumbs":4,"title":3},"766":{"body":54,"breadcrumbs":3,"title":2},"767":{"body":77,"breadcrumbs":2,"title":1},"768":{"body":22,"breadcrumbs":3,"title":2},"769":{"body":40,"breadcrumbs":2,"title":1},"77":{"body":18,"breadcrumbs":9,"title":2},"770":{"body":50,"breadcrumbs":3,"title":2},"771":{"body":105,"breadcrumbs":4,"title":3},"772":{"body":97,"breadcrumbs":3,"title":2},"773":{"body":0,"breadcrumbs":5,"title":4},"774":{"body":36,"breadcrumbs":2,"title":1},"775":{"body":20,"breadcrumbs":4,"title":3},"776":{"body":38,"breadcrumbs":4,"title":3},"777":{"body":29,"breadcrumbs":3,"title":2},"778":{"body":45,"breadcrumbs":3,"title":2},"779":{"body":121,"breadcrumbs":4,"title":3},"78":{"body":294,"breadcrumbs":10,"title":3},"780":{"body":21,"breadcrumbs":4,"title":3},"781":{"body":18,"breadcrumbs":4,"title":3},"782":{"body":10,"breadcrumbs":4,"title":3},"783":{"body":25,"breadcrumbs":4,"title":3},"784":{"body":10,"breadcrumbs":4,"title":3},"785":{"body":49,"breadcrumbs":4,"title":3},"786":{"body":21,"breadcrumbs":4,"title":3},"787":{"body":0,"breadcrumbs":4,"title":3},"788":{"body":17,"breadcrumbs":3,"title":2},"789":{"body":91,"breadcrumbs":3,"title":2},"79":{"body":79,"breadcrumbs":11,"title":4},"790":{"body":26,"breadcrumbs":3,"title":2},"791":{"body":22,"breadcrumbs":5,"title":4},"792":{"body":14,"breadcrumbs":4,"title":3},"793":{"body":7,"breadcrumbs":5,"title":4},"794":{"body":46,"breadcrumbs":2,"title":1},"795":{"body":14,"breadcrumbs":3,"title":2},"796":{"body":32,"breadcrumbs":3,"title":2},"797":{"body":36,"breadcrumbs":3,"title":2},"798":{"body":21,"breadcrumbs":3,"title":2},"799":{"body":0,"breadcrumbs":4,"title":3},"8":{"body":51,"breadcrumbs":3,"title":2},"80":{"body":79,"breadcrumbs":10,"title":3},"800":{"body":71,"breadcrumbs":3,"title":2},"81":{"body":23,"breadcrumbs":10,"title":5},"82":{"body":74,"breadcrumbs":6,"title":1},"83":{"body":36,"breadcrumbs":9,"title":4},"84":{"body":112,"breadcrumbs":7,"title":2},"85":{"body":128,"breadcrumbs":9,"title":4},"86":{"body":153,"breadcrumbs":10,"title":5},"87":{"body":17,"breadcrumbs":6,"title":1},"88":{"body":0,"breadcrumbs":7,"title":2},"89":{"body":36,"breadcrumbs":7,"title":2},"9":{"body":27,"breadcrumbs":3,"title":2},"90":{"body":81,"breadcrumbs":9,"title":3},"91":{"body":29,"breadcrumbs":8,"title":2},"92":{"body":34,"breadcrumbs":9,"title":3},"93":{"body":54,"breadcrumbs":9,"title":3},"94":{"body":16,"breadcrumbs":7,"title":1},"95":{"body":56,"breadcrumbs":8,"title":2},"96":{"body":22,"breadcrumbs":11,"title":5},"97":{"body":19,"breadcrumbs":11,"title":5},"98":{"body":419,"breadcrumbs":12,"title":6},"99":{"body":0,"breadcrumbs":8,"title":2}},"docs":{"0":{"body":"Table of Contents About Optimism About the OP Stack Site Navigation","breadcrumbs":"Introduction » OP Stack Specification","id":"0","title":"OP Stack Specification"},"1":{"body":"Optimism is a project dedicated to scaling Ethereum's technology and expanding its ability to coordinate people from across the world to build effective decentralized economies and governance systems. The Optimism Collective builds open-source software that powers scalable blockchains and aims to address key governance and economic challenges in the wider Ethereum ecosystem. Optimism operates on the principle of impact=profit , the idea that individuals who positively impact the Collective should be proportionally rewarded with profit. Change the incentives and you change the world.","breadcrumbs":"Introduction » About Optimism","id":"1","title":"About Optimism"},"10":{"body":"We strive to preserve three critical properties: liveness, validity, and availability. A protocol that can maintain these properties can, effectively, scale Ethereum without sacrificing security.","breadcrumbs":"Background » Protocol Guarantees","id":"10","title":"Protocol Guarantees"},"100":{"body":"This updates which L2 blocks the engine considers to be canonical (forkchoiceState argument), and optionally initiates block production (payloadAttributes argument). Within the rollup, the types of forkchoice updates translate as: headBlockHash: block hash of the head of the canonical chain. Labeled \"unsafe\" in user JSON-RPC. Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts. safeBlockHash: block hash of the canonical chain, derived from L1 data, unlikely to reorg. finalizedBlockHash: irreversible block hash, matches lower boundary of the dispute period. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV2 : the extended PayloadAttributesV2 Extended PayloadAttributesV2 PayloadAttributesV2 is extended to: PayloadAttributesV2: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The type notation used here refers to the HEX value encoding used by the Ethereum JSON-RPC API specification , as this structure will need to be sent over JSON-RPC. array refers to a JSON array. Each item of the transactions array is a byte list encoding a transaction: TransactionType || TransactionPayload or LegacyTransaction, as defined in EIP-2718 . This is equivalent to the transactions field in ExecutionPayloadV2 The transactions field is optional: If empty or missing: no changes to engine behavior. The sequencers will (if enabled) build a block by consuming transactions from the transaction pool. If present and non-empty: the payload MUST be produced starting with this exact list of transactions. The rollup driver determines the transaction list based on deterministic L1 inputs. The noTxPool is optional as well, and extends the transactions meaning: If false, the execution engine is free to pack additional transactions from external sources like the tx pool into the payload, after any of the transactions. This is the default behavior a L1 node implements. If true, the execution engine must not change anything about the given list of transactions. If the transactions field is present, the engine must execute the transactions in order and return STATUS_INVALID if there is an error processing the transactions. It must return STATUS_VALID if all of the transactions could be executed without error. Note : The state transition rules have been modified such that deposits will never fail so if engine_forkchoiceUpdatedV2 returns STATUS_INVALID it is because a batched transaction is invalid. The gasLimit is optional w.r.t. compatibility with L1, but required when used as rollup. This field overrides the gas limit used during block-building. If not specified as rollup, a STATUS_INVALID is returned.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV2","id":"100","title":"engine_forkchoiceUpdatedV2"},"101":{"body":"See engine_forkchoiceUpdatedV2 for a description of the forkchoice updated method. engine_forkchoiceUpdatedV3 must only be called with Ecotone payload. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV3 : the extended PayloadAttributesV3 Extended PayloadAttributesV3 PayloadAttributesV3 is extended to: PayloadAttributesV3: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 parentBeaconBlockRoot: DATA (32 bytes) transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The requirements of this object are the same as extended PayloadAttributesV2 with the addition of parentBeaconBlockRoot which is the parent beacon block root from the L1 origin block of the L2 block. Starting at Ecotone, the parentBeaconBlockRoot must be set to the L1 origin parentBeaconBlockRoot, or a zero bytes32 if the Dencun functionality with parentBeaconBlockRoot is not active on L1.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV3","id":"101","title":"engine_forkchoiceUpdatedV3"},"102":{"body":"No modifications to engine_newPayloadV2 . Applies a L2 block to the engine state.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV2","id":"102","title":"engine_newPayloadV2"},"103":{"body":"engine_newPayloadV3 applies an Ecotone L2 block to the engine state. There are no modifications to this API. engine_newPayloadV3 must only be called with Ecotone payload. The additional parameters should be set as follows: expectedBlobVersionedHashes MUST be an empty array. parentBeaconBlockRoot MUST be the parent beacon block root from the L1 origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV3","id":"103","title":"engine_newPayloadV3"},"104":{"body":"No modifications to engine_getPayloadV2 . Retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV2 when called with payloadAttributes.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV2","id":"104","title":"engine_getPayloadV2"},"105":{"body":"engine_getPayloadV3 retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV3 when called with payloadAttributes. engine_getPayloadV3 must only be called with Ecotone payload. Extended Response The response is extended to: { executionPayload: ExecutionPayload blockValue: QUANTITY blobsBundle: BlobsBundle shouldOverrideBuilder: BOOLEAN parentBeaconBlockRoot: DATA (32 bytes)\n} In Ecotone it MUST be set to the parentBeaconBlockRoot from the L1 Origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV3","id":"105","title":"engine_getPayloadV3"},"106":{"body":"Optional extension to the Engine API. Signals superchain information to the Engine: V1 signals which protocol version is recommended and required. Types: SuperchainSignal: { recommended: ProtocolVersion; required: ProtocolVersion;\n} ProtocolVersion: encoded for RPC as defined in Protocol Version format specification . Parameters: signal: SuperchainSignal, the signaled superchain information. Returns: ProtocolVersion: the latest supported OP-Stack protocol version of the execution engine. The execution engine SHOULD warn the user when the recommended version is newer than the current version supported by the execution engine. The execution engine SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the execution engine operator.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_signalSuperchainV1","id":"106","title":"engine_signalSuperchainV1"},"107":{"body":"The execution engine can acquire all data through the rollup node, as derived from L1: P2P networking is strictly optional. However, to not bottleneck on L1 data retrieval speed, the P2P network functionality SHOULD be enabled, serving: Peer discovery ( Disc v5 ) eth/66 : Transaction pool (consumed by sequencer nodes) State sync (happy-path for fast trustless db replication) Historical block header and body retrieval New blocks are acquired through the consensus layer instead (rollup node) No modifications to L1 network functionality are required, except configuration: networkID : Distinguishes the L2 network from L1 and testnets. Equal to the chainID of the rollup network. Activate Merge fork: Enables Engine API and disables propagation of blocks, as block headers cannot be authenticated without consensus layer. Bootnode list: DiscV5 is a shared network, bootstrap is faster through connecting with L2 nodes first.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Networking","id":"107","title":"Networking"},"108":{"body":"The execution engine can operate sync in different ways: Happy-path: rollup node informs engine of the desired chain head as determined by L1, completes through engine P2P. Worst-case: rollup node detects stalled engine, completes sync purely from L1 data, no peers required. The happy-path is more suitable to bring new nodes online quickly, as the engine implementation can sync state faster through methods like snap-sync .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Sync","id":"108","title":"Sync"},"109":{"body":"The rollup node informs the engine of the L2 chain head, unconditionally (part of regular node operation): Bedrock / Canyon / Delta Payloads engine_newPayloadV2 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV2 is called with the current unsafe/safe/finalized L2 block hashes. Ecotone Payloads engine_newPayloadV3 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV3 is called with the current unsafe/safe/finalized L2 block hashes. The engine requests headers from peers, in reverse till the parent hash matches the local chain The engine catches up: a) A form of state sync is activated towards the finalized or head block hash b) A form of block sync pulls block bodies and processes towards head block hash The exact P2P based sync is out of scope for the L2 specification: the operation within the engine is the exact same as with L1 (although with an EVM that supports deposits).","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Happy-path sync","id":"109","title":"Happy-path sync"},"11":{"body":"Liveness is defined as the ability for any party to be able to extend the rollup chain by including a transaction within a bounded amount of time. It should not be possible for an actor to block the inclusion of any given transaction for more than this bounded time period. This bounded time period should also be acceptable such that inclusion is not just theoretically possible but practically useful.","breadcrumbs":"Background » Liveness","id":"11","title":"Liveness"},"110":{"body":"Engine is out of sync, not peered and/or stalled due other reasons. The rollup node maintains latest head from engine (poll eth_getBlockByNumber and/or maintain a header subscription) The rollup node activates sync if the engine is out of sync but not syncing through P2P (eth_syncing) The rollup node inserts blocks, derived from L1, one by one, potentially adapting to L1 reorg(s), as outlined in the rollup node spec .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Worst-case sync","id":"110","title":"Worst-case sync"},"111":{"body":"EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction, plus a list of \"blobs\": \"Binary Large Object\", i.e. a dedicated data type for serving Data-Availability as base-layer. With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception: as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type. EIP-4844 is disabled as following: Transaction network-layer announcements, announcing blob-type transactions, are ignored. Transactions of the blob-type, through the RPC or otherwise, are not allowed into the transaction pool. Block-building code does not select EIP-4844 transactions. An L2 block state-transition with EIP-4844 transactions is invalid. The BLOBBASEFEE opcode is present but its semantics are altered because there are no blobs processed by L2. The opcode will always push a value of 1 onto the stack.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: disable Blob-transactions","id":"111","title":"Ecotone: disable Blob-transactions"},"112":{"body":"EIP-4788 introduces a \"beacon block root\" into the execution-layer block-header and EVM. This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block. With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO of L1. And thus with EIP-4788 the L1 beacon block root is made available. For the Ecotone upgrade, this entails that: The parent_beacon_block_root of the L1 origin is now embedded in the L2 block header. The \"Beacon roots contract\" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis. The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: Beacon Block Root","id":"112","title":"Ecotone: Beacon Block Root"},"113":{"body":"The Ethereum Node Record (ENR) for an Optimism execution node must contain an opel key-value pair where the key is opel and the value is a EIP-2124 fork id. The EL uses a different key from the CL in order to stop EL and CL nodes from connecting to each other.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » P2P Modifications","id":"113","title":"P2P Modifications"},"114":{"body":"Table of Contents Overview Driver Derivation L2 Output RPC method Structures BlockID L1BlockRef L2BlockRef SyncStatus Output Method API Protocol Version tracking","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node Specification","id":"114","title":"Rollup Node Specification"},"115":{"body":"The rollup node is the component responsible for deriving the L2 chain from L1 blocks (and their associated receipts ). The part of the rollup node that derives the L2 chain is called the rollup driver . This document is currently only concerned with the specification of the rollup driver.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Overview","id":"115","title":"Overview"},"116":{"body":"The task of the driver in the rollup node is to manage the derivation process: Keep track of L1 head block Keep track of the L2 chain sync progress Iterate over the derivation steps as new inputs become available","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Driver","id":"116","title":"Driver"},"117":{"body":"This process happens in three steps: Select inputs from the L1 chain, on top of the last L2 block: a list of blocks, with transactions and associated data and receipts. Read L1 information, deposits, and sequencing batches in order to generate payload attributes (essentially a block without output properties ). Pass the payload attributes to the execution engine , so that the L2 block (including output block properties ) may be computed. While this process is conceptually a pure function from the L1 chain to the L2 chain, it is in practice incremental. The L2 chain is extended whenever new L1 blocks are added to the L1 chain. Similarly, the L2 chain re-organizes whenever the L1 chain re-organizes . For a complete specification of the L2 block derivation, refer to the L2 block derivation document .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation","id":"117","title":"Derivation"},"118":{"body":"The Rollup node has its own RPC method, optimism_outputAtBlock which returns a 32 byte hash corresponding to the L2 output root .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » L2 Output RPC method","id":"118","title":"L2 Output RPC method"},"119":{"body":"These define the types used by rollup node API methods. The types defined here are extended from the engine API specs . BlockID hash: DATA, 32 Bytes number: QUANTITY, 64 Bits L1BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits L2BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits l1origin: BlockID sequenceNumber: QUANTITY, 64 Bits - distance to first block of epoch SyncStatus Represents a snapshot of the rollup driver. current_l1: Object - instance of L1BlockRef . current_l1_finalized: Object - instance of L1BlockRef . head_l1: Object - instance of L1BlockRef . safe_l1: Object - instance of L1BlockRef . finalized_l1: Object - instance of L1BlockRef . unsafe_l2: Object - instance of L2BlockRef . safe_l2: Object - instance of L2BlockRef . finalized_l2: Object - instance of L2BlockRef . pending_safe_l2: Object - instance of L2BlockRef . queued_unsafe_l2: Object - instance of L2BlockRef .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Structures","id":"119","title":"Structures"},"12":{"body":"Validity is defined as the ability for any party to execute the rollup state transition function, subject to certain lower bound expectations for available computing and bandwidth resources. Validity is also extended to refer to the ability for a smart contract on Ethereum to be able to validate this state transition function economically.","breadcrumbs":"Background » Validity","id":"12","title":"Validity"},"120":{"body":"The input and return types here are as defined by the engine API specs . method: optimism_outputAtBlock params: blockNumber: QUANTITY, 64 bits - L2 integer block number. returns: version: DATA, 32 Bytes - the output root version number, beginning with 0. outputRoot: DATA, 32 Bytes - the output root. blockRef: Object - instance of L2BlockRef . withdrawalStorageRoot: 32 bytes - storage root of the L2toL1MessagePasser contract. stateRoot: DATA: 32 bytes - the state root. syncStatus: Object - instance of SyncStatus .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Output Method API","id":"120","title":"Output Method API"},"121":{"body":"The rollup-node should monitor the recommended and required protocol version by monitoring the Protocol Version contract on L1, as specified in the Superchain Version Signaling specifications . This can be implemented through polling in the Driver loop. After polling the Protocol Version, the rollup node SHOULD communicate it with the execution-engine through an engine_signalSuperchainV1 call. The rollup node SHOULD warn the user when the recommended version is newer than the current version supported by the rollup node. The rollup node SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the rollup node operator.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Protocol Version tracking","id":"121","title":"Protocol Version tracking"},"122":{"body":"Table of Contents Overview P2P configuration Identification Discv5 Consensus Layer Structure LibP2P Transport Dialing NAT Peer management Transport security Protocol negotiation Identify Ping Multiplexing GossipSub Content-based message identification Message compression and limits Message ID computation Heartbeat and parameters Topic configuration Topic validation Gossip Topics blocksv1 blocksv2 blocksv3 Block encoding Block signatures Block validation Block processing Block topic scoring parameters Req-Resp payload_by_number","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Rollup-node P2P interface","id":"122","title":"Rollup-node P2P interface"},"123":{"body":"The rollup node has an optional peer-to-peer (P2P) network service to improve the latency between the view of sequencers and the rest of the network by bypassing the L1 in the happy case, without relying on a single centralized endpoint. This also enables faster historical sync to be bootstrapped by providing block headers to sync towards, and only having to compare the L2 chain inputs to the L1 data as compared to processing everything one block at a time. The rollup node will always prioritize L1 and reorganize to match the canonical chain. The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the \"unsafe\" chain, to improve the happy case performance. This also means that P2P behavior is a soft-rule: nodes keep each other in check with scoring and eventual banning of malicious peers by identity or IP. Any behavior on the P2P layer does not affect the rollup security, at worst nodes rely on higher-latency data from L1 to serve. In summary, the P2P stack looks like: Discovery to find peers: Discv5 Connections, peering, transport security, multiplexing, gossip: LibP2P Application-layer publishing and validation of gossiped messages like L2 blocks. This document only specifies the composition and configuration of these network libraries. These components have their own standards, implementations in Go/Rust/Java/Nim/JS/more, and are adopted by several other blockchains, most notably the L1 consensus layer (Eth2) .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Overview","id":"123","title":"Overview"},"124":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » P2P configuration","id":"124","title":"P2P configuration"},"125":{"body":"Nodes have a separate network- and consensus-identity. The network identity is a secp256k1 key, used for both discovery and active LibP2P connections. Common representations of network identity: PeerID: a LibP2P specific ID derived from the pubkey (through protobuf encoding, typing and hashing) NodeID: a Discv5 specific ID derived from the pubkey (through hashing, used in the DHT) Multi-address: an unsigned address, containing: IP, TCP port, PeerID ENR: a signed record used for discovery, containing: IP, TCP port, UDP port, signature (pubkey can be derived) and L2 network identification. Generally encoded in base64.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Identification","id":"125","title":"Identification"},"126":{"body":"Consensus Layer Structure The Ethereum Node Record (ENR) for an Optimism rollup node must contain the following values, identified by unique keys: An IPv4 address (ip field) and/or IPv6 address (ip6 field). A TCP port (tcp field) representing the local libp2p listening port. A UDP port (udp field) representing the local discv5 listening port. An OpStack (opstack field) L2 network identifier The opstack value is encoded as a single RLP bytes value, the concatenation of: chain ID (unsigned varint) fork ID (unsigned varint) Note that DiscV5 is a shared DHT (Distributed Hash Table): the L1 consensus and execution nodes, as well as testnet nodes, and even external IOT nodes, all communicate records in this large common DHT. This makes it more difficult to censor the discovery of node records. The discovery process in Optimism is a pipeline of node records: Fill the table with FINDNODES if necessary (Performed by Discv5 library) Pull additional records with searches to random Node IDs if necessary (e.g. iterate RandomNodes() in Go implementation) Pull records from the DiscV5 module when looking for peers Check if the record contains the opstack entry, verify it matches the chain ID and current or future fork number If not already connected, and not recently disconnected or put on deny-list, attempt to dial.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Discv5","id":"126","title":"Discv5"},"127":{"body":"Transport TCP transport. Additional transports are supported by LibP2P, but not required. Dialing Nodes should be publicly dialable, not rely on relay extensions, and able to dial both IPv4 and IPv6. NAT The listening endpoint must be publicly facing, but may be configured behind a NAT. LibP2P will use PMP / UPNP based techniques to track the external IP of the node. It is recommended to disable the above if the external IP is static and configured manually. Peer management The default is to maintain a peer count with a tide-system based on active peer count: At \"low tide\" the node starts to actively search for additional peer connections. At \"high tide\" the node starts to prune active connections, except those that are marked as trusted or have a grace period. Peers will have a grace period for a configurable amount of time after joining. In an emergency, when memory runs low, the node should start pruning more aggressively. Peer records can be persisted to disk to quickly reconnect with known peers after restarting the rollup node. The discovery process feeds the peerstore with peer records to connect to, tagged with a time-to-live (TTL). The current P2P processes do not require selective topic-specific peer connections, other than filtering for the basic network participation requirement. Peers may be banned if their performance score is too low, or if an objectively malicious action was detected. Banned peers will be persisted to the same data-store as the peerstore records. TODO: the connection gater does currently not gate by IP address on the dial Accept-callback. Transport security Libp2p-noise , XX handshake, with the secp256k1 P2P identity, as popularized in Eth2. The TLS option is available as well, but noise should be prioritized in negotiation. Protocol negotiation Multistream-select 1.0 (/multistream/1.0.0) is an interactive protocol used to negotiate sub-protocols supported in LibP2P peers. Multistream-select 2.0 may be used in the future. Identify LibP2P offers a minimal identification module to share client version and programming language. This is optional and can be disabled for enhanced privacy. It also includes the same protocol negotiation information, which can speed up initial connections. Ping LibP2P includes a simple ping protocol to track latency between connections. This should be enabled to help provide insight into the network health. Multiplexing For async communication over different channels over the same connection, multiplexing is used. mplex (/mplex/6.7.0) is required, and yamux (/yamux/1.0.0) is recommended but optional GossipSub GossipSub 1.1 (/meshsub/1.1.0, i.e. with peer-scoring extension) is a pubsub protocol for mesh-networks, deployed on L1 consensus (Eth2) and other protocols such as Filecoin, offering lots of customization options. Content-based message identification Messages are deduplicated, and filtered through application-layer signature verification. Thus origin-stamping is disabled and published messages must only contain application data, enforced through a StrictNoSign Signature Policy This provides greater privacy, and allows sequencers (consensus identity) to maintain multiple network identities for redundancy. Message compression and limits The application contents are compressed with snappy single-block-compression (as opposed to frame-compression), and constrained to 10 MiB. Message ID computation Same as L1 , with recognition of compression: If message.data has a valid snappy decompression, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_VALID_SNAPPY with the snappy decompressed message data, i.e. SHA256(MESSAGE_DOMAIN_VALID_SNAPPY + snappy_decompress(message.data))[:20]. Otherwise, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_INVALID_SNAPPY with the raw message data, i.e. SHA256(MESSAGE_DOMAIN_INVALID_SNAPPY + message.data)[:20]. Heartbeat and parameters GossipSub parameters : D (topic stable mesh target count): 8 D_low (topic stable mesh low watermark): 6 D_high (topic stable mesh high watermark): 12 D_lazy (gossip target): 6 heartbeat_interval (interval of heartbeat, in seconds): 0.5 fanout_ttl (ttl for fanout maps for topics we are not subscribed to but have published to, in seconds): 24 mcache_len (number of windows to retain full messages in cache for IWANT responses): 12 mcache_gossip (number of windows to gossip about): 3 seen_ttl (number of heartbeat intervals to retain message IDs): 130 (= 65 seconds) Notable differences from L1 consensus (Eth2): seen_ttl does not need to cover a full L1 epoch (6.4 minutes), but rather just a small window covering latest blocks fanout_ttl: adjusted to lower than seen_ttl mcache_len: a larger number of heartbeats can be retained since the gossip is much less noisy. heartbeat_interval: faster interval to reduce latency, bandwidth should still be reasonable since there are far fewer messages to gossip about each interval than on L1 which uses an interval of 0.7 seconds. Topic configuration Topics have string identifiers and are communicated with messages and subscriptions. /optimism/chain_id/hardfork_version/Name chain_id: replace with decimal representation of chain ID hardfork_version: replace with decimal representation of hardfork, starting at 0 Name: topic application-name Note that the topic encoding depends on the topic, unlike L1, since there are less topics, and all are snappy-compressed. Topic validation To ensure only valid messages are relayed, and malicious peers get scored based on application behavior, an extended validator checks the message before it is relayed or processed. The extended validator emits one of the following validation signals: ACCEPT valid, relayed to other peers and passed to local topic subscriber IGNORE scored like inactivity, message is dropped and not processed REJECT score penalties, message is dropped","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » LibP2P","id":"127","title":"LibP2P"},"128":{"body":"There are three topics for distributing blocks to other nodes faster than proxying through L1 would. These are:","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Gossip Topics","id":"128","title":"Gossip Topics"},"129":{"body":"Pre-Canyon/Shanghai blocks are broadcast on /optimism//0/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv1","id":"129","title":"blocksv1"},"13":{"body":"Availability is defined as the ability for any party to retrieve the inputs that are necessary to execute the rollup state transition function correctly. Availability is essentially an element of validity and is required to be able to guarantee validity in general. Similar to validity, availability is subject to lower bound resource requirements.","breadcrumbs":"Background » Availability","id":"13","title":"Availability"},"130":{"body":"Canyon/Delta blocks are broadcast on /optimism//1/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv2","id":"130","title":"blocksv2"},"131":{"body":"Ecotone blocks are broadcast on /optimism//2/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv3","id":"131","title":"blocksv3"},"132":{"body":"A block is structured as the concatenation of: V1 and V2 topics signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. V3 topic signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) parentBeaconBlockRoot: L1 origin parent beacon block root, always 32 bytes payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. All topics use Snappy block-compression (i.e. no snappy frames): the above needs to be compressed after encoding, and decompressed before decoding.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block encoding","id":"132","title":"Block encoding"},"133":{"body":"The signature is a secp256k1 signature, and signs over a message: keccak256(domain ++ chain_id ++ payload_hash), where: domain is 32 bytes, reserved for message types and versioning info. All zero for this signature. chain_id is a big-endian encoded uint256. payload_hash is keccak256(payload), where payload is the payload in V1 and V2, and parentBeaconBlockRoot ++ payload in V3. The secp256k1 signature must have y_parity = 1 or 0, the chain_id is already signed over.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block signatures","id":"133","title":"Block signatures"},"134":{"body":"An extended-validator checks the incoming messages as follows, in order of operation: [REJECT] if the compression is not valid [REJECT] if the block encoding is not valid [REJECT] if the payload.timestamp is older than 60 seconds in the past (graceful boundary for worst-case propagation and clock skew) [REJECT] if the payload.timestamp is more than 5 seconds into the future [REJECT] if the block_hash in the payload is not valid [REJECT] if the block is on the V1 topic and has withdrawals [REJECT] if the block is on the V1 topic and has a withdrawals list [REJECT] if the block is on a topic >= V2 and does not have an empty withdrawals list [REJECT] if the block is on a topic <= V2 and has a blob gas-used value set [REJECT] if the block is on a topic <= V2 and has an excess blob gas value set [REJECT] if the block is on a topic >= V3 and has a blob gas-used value that is not zero [REJECT] if the block is on a topic >= V3 and has an excess blob gas value that is not zero [REJECT] if the block is on a topic <= V2 and the parent beacon block root is not nil [REJECT] if the block is on a topic >= V3 and the parent beacon block root is nil [REJECT] if more than 5 different blocks have been seen with the same block height [IGNORE] if the block has already been seen [REJECT] if the signature by the sequencer is not valid Mark the block as seen for the given block height The block is signed by the corresponding sequencer, to filter malicious messages. The sequencer model is singular but may change to multiple sequencers in the future. A default sequencer pubkey is distributed with rollup nodes and should be configurable. Note that blocks that a block may still be propagated even if the L1 already confirmed a different block. The local L1 view of the node may be wrong, and the time and signature validation will prevent spam. Hence, calling into the execution engine with a block lookup every propagation step is not worth the added delay. Block processing A node may apply the block to their local engine ahead of L1 availability, if it ensures that: The application of the block is reversible, in case of a conflict with delayed L1 information The subsequent forkchoice-update ensures this block is recognized as \"unsafe\" (see fork choice updated ) Block topic scoring parameters TODO: GossipSub per-topic scoring to fine-tune incentives for ideal propagation delay and bandwidth usage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block validation","id":"134","title":"Block validation"},"135":{"body":"The op-node implements a similar request-response encoding for its sync protocols as the L1 ethereum Beacon-Chain. See L1 P2P-interface req-resp specification and Altair P2P update . However, the protocol is simplified, to avoid several issues seen in L1: Error strings in responses, if there is any alternative response, should not need to be compressed or have an artificial global length limit. Payload lengths should be fixed-length: byte-by-byte uvarint reading from the underlying stream is undesired. are relaxed to encode a uint32, rather than a beacon-chain ForkDigest. Payload-encoding may change per hardfork, so is not part of the protocol-ID. Usage of response-chunks is specific to the req-resp method: most basic req-resp does not need chunked responses. Compression is encouraged to be part of the payload-encoding, specific to the req-resp method, where necessary: pings and such do not need streaming frame compression etc. And the protocol ID format follows the same scheme as L1, except the trailing encoding schema part, which is now message-specific: /ProtocolPrefix/MessageName/SchemaVersion/ The req-resp protocols served by the op-node all have /ProtocolPrefix set to /opstack/req. Individual methods may include the chain ID as part of the /MessageName segment, so it's immediately clear which chain the method applies to, if the communication is chain-specific. Other methods may include chain-information in the request and/or response data, such as the ForkDigest in L1 beacon chain req-resp protocols. Each segment starts with a /, and may contain multiple /, and the final protocol ID is suffixed with a /.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Req-Resp","id":"135","title":"Req-Resp"},"136":{"body":"This is an optional chain syncing method, to request/serve execution payloads by number. This serves as a method to fill gaps upon missed gossip, and sync short to medium ranges of unsafe L2 blocks. Protocol ID: /opstack/req/payload_by_number//0/ /MessageName is /block_by_number/ where is set to the op-node L2 chain ID. /SchemaVersion is /0 Request format: : a little-endian uint64 - the block number to request. Response format: = is a byte code describing the result. 0 on success, should follow. 1 if valid request, but unavailable payload. 2 if invalid request 3+ if other error The >= 128 range is reserved for future use. is a little-endian uint32, identifying the response type (fork-specific) is an encoded block, read till stream EOF. The input of should be limited, as well as any generated decompressed output, to avoid unexpected resource usage or zip-bomb type attacks. A 10 MB limit is recommended, to ensure all blocks may be synced. Implementations may opt for a different limit, since this sync method is optional. list: 0: SSZ-encoded ExecutionPayload, with Snappy framing compression, matching the ExecutionPayload SSZ definition of the L1 Merge, L2 Bedrock and L2 Regolith, L2 Canyon versions. 1: SSZ-encoded ExecutionPayloadEnvelope with Snappy framing compression, matching the ExecutionPayloadEnvelope SSZ definition of the L2 Ecotone version. The request is by block-number, enabling parallel fetching of a chain across many peers. A res = 0 response should be verified to: Have a block-number matching the requested block number. Have a consistent blockhash w.r.t. the other block contents. Build towards a known canonical block. This can be verified by checking if the parent-hash of a previous trusted canonical block matches that of the verified hash of the retrieved block. For unsafe blocks this may be relaxed to verification against the parent-hash of any previously trusted block: The gossip validation process limits the amount of blocks that may be trusted to sync towards. The unsafe blocks should be queued for processing, the latest received L2 unsafe blocks should always override any previous chain, until the final L2 chain can be reproduced from L1 data. A res > 0 response code should not be accepted. The result code is helpful for debugging, but the client should regard any error like any other unanswered request, as the responding peer cannot be trusted.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » payload_by_number","id":"136","title":"payload_by_number"},"137":{"body":"Table of Contents Overview Eager Block Derivation Protocol Parameters Batch Submission Sequencing & Batch Submission Overview Batch Submission Wire Format Batcher Transaction Format Frame Format Channel Format Batch Format Architecture L2 Chain Derivation Pipeline L1 Traversal L1 Retrieval Frame Queue Channel Bank Pruning Timeouts Reading Loading frames Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue Engine API usage Bedrock, Canyon, Delta: API Usage Ecotone: API Usage Forkchoice synchronization L1-consolidation: payload attributes matching L1-sync: payload attributes processing Processing unsafe payload attributes Resetting the Pipeline Finding the sync starting point Resetting derivation stages About reorgs Post-Merge Deriving Payload Attributes Deriving the Transaction List Network upgrade automation transactions Ecotone L1Block Deployment GasPriceOracle Deployment L1Block Proxy Update GasPriceOracle Proxy Update GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) Building Individual Payload Attributes","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Specification","id":"137","title":"L2 Chain Derivation Specification"},"138":{"body":"Note the following assumes a single sequencer and batcher. In the future, the design will be adapted to accommodate multiple such entities. L2 chain derivation — deriving L2 blocks from L1 data — is one of the main responsibilities of the rollup node , both in validator mode, and in sequencer mode (where derivation acts as a sanity check on sequencing, and enables detecting L1 chain re-organizations ). The L2 chain is derived from the L1 chain. In particular, each L1 block following L2 chain inception is mapped to a sequencing epoch comprising at least one L2 block. Each L2 block belongs to exactly one epoch, and we call the corresponding L1 block its L1 origin . The epoch's number equals that of its L1 origin block. To derive the L2 blocks of epoch number E, we need the following inputs: L1 blocks in the range [E, E + SWS), called the sequencing window of the epoch, and SWS the sequencing window size. (Note that sequencing windows overlap.) Batcher transactions from blocks in the sequencing window. These transactions allow us to reconstruct the epoch's sequencer batches , each of which will produce one L2 block. Note that: The L1 origin will never contain any data needed to construct sequencer batches since each batch must contain the L1 origin hash. An epoch may have no sequencer batches. Deposits made in the L1 origin (in the form of events emitted by the deposit contract ). L1 block attributes from the L1 origin (to derive the L1 attributes deposited transaction ). The state of the L2 chain after the last L2 block of the previous epoch, or the L2 genesis state if E is the first epoch. To derive the whole L2 chain from scratch, we start with the L2 genesis state and the L2 genesis block as the first L2 block. We then derive L2 blocks from each epoch in order, starting at the first L1 block following L2 chain inception . Refer to the Architecture section for more information on how we implement this in practice. The L2 chain may contain pre-Bedrock history, but the L2 genesis here refers to the Bedrock L2 genesis block. Each L2 block with origin l1_origin is subject to the following constraints (whose values are denominated in seconds): block.timestamp = prev_l2_timestamp + l2_block_time prev_l2_timestamp is the timestamp of the L2 block immediately preceding this one. If there is no preceding block, then this is the genesis block, and its timestamp is explicitly specified. l2_block_time is a configurable parameter of the time between L2 blocks (2s on Optimism). l1_origin.timestamp <= block.timestamp <= max_l2_timestamp, where max_l2_timestamp = max(l1_origin.timestamp + max_sequencer_drift, prev_l2_timestamp + l2_block_time) max_sequencer_drift is a configurable parameter that bounds how far the sequencer can get ahead of the L1. Finally, each epoch must have at least one L2 block. The first constraint means there must be an L2 block every l2_block_time seconds following L2 chain inception. The second constraint ensures that an L2 block timestamp never precedes its L1 origin timestamp, and is never more than max_sequencer_drift ahead of it, except only in the unusual case where it might prohibit an L2 block from being produced every l2_block_time seconds. (Such cases might arise for example under a proof-of-work L1 that sees a period of rapid L1 block production.) In either case, the sequencer enforces len(batch.transactions) == 0 while max_sequencer_drift is exceeded. See Batch Queue for more details. The final requirement that each epoch must have at least one L2 block ensures that all relevant information from the L1 (e.g. deposits) is represented in the L2, even if it has no sequencer batches. Post-merge, Ethereum has a fixed 12s block time , though some slots can be skipped. Under a 2s L2 block time, we thus expect each epoch to typically contain 12/2 = 6 L2 blocks. The sequencer will however produce bigger epochs in order to maintain liveness in case of either a skipped slot on the L1 or a temporary loss of connection to it. For the lost connection case, smaller epochs might be produced after the connection was restored to keep L2 timestamps from drifting further and further ahead.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Overview","id":"138","title":"Overview"},"139":{"body":"Deriving an L2 block requires that we have constructed its sequencer batch and derived all L2 blocks and state updates prior to it. This means we can typically derive the L2 blocks of an epoch eagerly without waiting on the full sequencing window. The full sequencing window is required before derivation only in the very worst case where some portion of the sequencer batch for the first block of the epoch appears in the very last L1 block of the window. Note that this only applies to block derivation. Sequencer batches can still be derived and tentatively queued without deriving blocks from them.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Eager Block Derivation","id":"139","title":"Eager Block Derivation"},"14":{"body":"Generally speaking, there are three primary actors that interact with an OP Stack chain: users, sequencers, and verifiers. graph TD EthereumL1(Ethereum L1) subgraph \"L2 Participants\" Users(Users) Sequencers(Sequencers) Verifiers(Verifiers) end Verifiers -.->|fetch transaction batches| EthereumL1 Verifiers -.->|fetch deposit data| EthereumL1 Verifiers -->|submit/validate/challenge output proposals| EthereumL1 Verifiers -.->|fetch realtime P2P updates| Sequencers Users -->|submit deposits/withdrawals| EthereumL1 Users -->|submit transactions| Sequencers Users -->|query data| Verifiers Sequencers -->|submit transaction batches| EthereumL1 Sequencers -.->|fetch deposit data| EthereumL1 classDef l1Contracts stroke:#bbf,stroke-width:2px; classDef l2Components stroke:#333,stroke-width:2px; classDef systemUser stroke:#f9a,stroke-width:2px; class EthereumL1 l1Contracts; class Users,Sequencers,Verifiers l2Components;","breadcrumbs":"Background » Network Participants","id":"14","title":"Network Participants"},"140":{"body":"The following table gives an overview of some protocol parameters, and how they are affected by protocol upgrades. Parameter Bedrock (default) value Latest (default) value Changes Notes max_sequencer_drift 600 1800 Fjord Changed from a chain parameter to a constant with Fjord. MAX_RLP_BYTES_PER_CHANNEL 10,000,000 100,000,000 Fjord Constant increased with Fjord. MAX_CHANNEL_BANK_SIZE 100,000,000 1,000,000,000 Fjord Constant increased with Fjord. MAX_SPAN_BATCH_ELEMENT_COUNT 10,000,000 10,000,000 Effectively introduced in Fjord Number of elements","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Protocol Parameters","id":"140","title":"Protocol Parameters"},"141":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission","id":"141","title":"Batch Submission"},"142":{"body":"The sequencer accepts L2 transactions from users. It is responsible for building blocks out of these. For each such block, it also creates a corresponding sequencer batch . It is also responsible for submitting each batch to a data availability provider (e.g. Ethereum calldata), which it does via its batcher component. The difference between an L2 block and a batch is subtle but important: the block includes an L2 state root, whereas the batch only commits to transactions at a given L2 timestamp (equivalently: L2 block number). A block also includes a reference to the previous block (*). (*) This matters in some edge case where a L1 reorg would occur and a batch would be reposted to the L1 chain but not the preceding batch, whereas the predecessor of an L2 block cannot possibly change. This means that even if the sequencer applies a state transition incorrectly, the transactions in the batch will still be considered part of the canonical L2 chain. Batches are still subject to validity checks (i.e. they have to be encoded correctly), and so are individual transactions within the batch (e.g. signatures have to be valid). Invalid batches and invalid individual transactions within an otherwise valid batch are discarded by correct nodes. If the sequencer applies a state transition incorrectly and posts an output root , then this output root will be incorrect. The incorrect output root will be challenged by a fault proof , then replaced by a correct output root for the existing sequencer batches. Refer to the Batch Submission specification for more information.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Sequencing & Batch Submission Overview","id":"142","title":"Sequencing & Batch Submission Overview"},"143":{"body":"Batch submission is closely tied to L2 chain derivation because the derivation process must decode the batches that have been encoded for the purpose of batch submission. The batcher submits batcher transactions to a data availability provider . These transactions contain one or multiple channel frames , which are chunks of data belonging to a channel . A channel is a sequence of sequencer batches (for any L2 blocks) compressed together. The reason to group multiple batches together is simply to obtain a better compression rate, hence reducing data availability costs. Channels might be too large to fit in a single batcher transaction , hence we need to split it into chunks known as channel frames . A single batcher transaction can also carry multiple frames (belonging to the same or to different channels). This design gives use the maximum flexibility in how we aggregate batches into channels, and split channels over batcher transactions. It notably allows us to maximize data utilization in a batcher transaction: for instance it allows us to pack the final (small) frame of one channel with one or more frames from the next channel. Also note that we use a streaming compression scheme, and we do not need to know how many batches a channel will end up containing when we start a channel, or even as we send the first frames in the channel. And by splitting channels across multiple data transactions, the L2 can have larger block data than the data-availability layer may support. All of this is illustrated in the following diagram. Explanations below. batch derivation chain diagram The first line represents L1 blocks with their numbers. The boxes under the L1 blocks represent batcher transactions included within the block. The squiggles under the L1 blocks represent deposits (more specifically, events emitted by the deposit contract ). Each colored chunk within the boxes represents a channel frame . So A and B are channels whereas A0, A1, B0, B1, B2 are frames. Notice that: multiple channels are interleaved frames do not need to be transmitted in order a single batcher transaction can carry frames from multiple channels In the next line, the rounded boxes represent individual sequencer batches that were extracted from the channels. The four blue/purple/pink were derived from channel A while the other were derived from channel B. These batches are here represented in the order they were decoded from batches (in this case B is decoded first). Note The caption here says \"Channel B was seen first and will be decoded into batches first\", but this is not a requirement. For instance, it would be equally acceptable for an implementation to peek into the channels and decode the one that contains the oldest batches first. The rest of the diagram is conceptually distinct from the first part and illustrates L2 chain derivation after the channels have been reordered. The first line shows batcher transactions. Note that in this case, there exists an ordering of the batches that makes all frames within the channels appear contiguously. This is not true in general. For instance, in the second transaction, the position of A1 and B0 could have been inverted for exactly the same result — no changes needed in the rest of the diagram. The second line shows the reconstructed channels in proper order. The third line shows the batches extracted from the channel. Because the channels are ordered and the batches within a channel are sequential, this means the batches are ordered too. The fourth line shows the L2 block derived from each batch. Note that we have a 1-1 batch to block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there are \"gaps\" in the batches posted on L1. The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while the second number (the \"sequence number\") denotes the position within the epoch. Finally, the sixth line shows user-deposited transactions derived from the deposit contract event mentioned earlier. Note the 101-0 L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if frame B2 indicates that it is the last frame within the channel and (2) no empty blocks must be inserted. The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4 blocks, because the last frame of channel A appears in block 102, but belong to epoch 99. As for the comment on \"security types\", it explains the classification of blocks as used on L1 and L2. Unsafe L2 blocks : Safe L2 blocks : Finalized L2 blocks: refer to block that have been derived from finalized L1 data. These security levels map to the headBlockHash, safeBlockHash and finalizedBlockHash values transmitted when interacting with the execution-engine API .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission Wire Format","id":"143","title":"Batch Submission Wire Format"},"144":{"body":"Batcher transactions are encoded as version_byte ++ rollup_payload (where ++ denotes concatenation). version_byte rollup_payload 0 frame ... (one or more frames, concatenated) 1 da_commitment (experimental, see alt-da ) Unknown versions make the batcher transaction invalid (it must be ignored by the rollup node). All frames in a batcher transaction must be parseable. If any one frame fails to parse, the all frames in the transaction are rejected. Batch transactions are authenticated by verifying that the to address of the transaction matches the batch inbox address, and the from address matches the batch-sender address in the system configuration at the time of the L1 block that the transaction data is read from.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batcher Transaction Format","id":"144","title":"Batcher Transaction Format"},"145":{"body":"A channel frame is encoded as: frame = channel_id ++ frame_number ++ frame_data_length ++ frame_data ++ is_last channel_id = bytes16\nframe_number = uint16\nframe_data_length = uint32\nframe_data = bytes\nis_last = bool Where uint32 and uint16 are all big-endian unsigned integers. Type names should be interpreted to and encoded according to the Solidity ABI . All data in a frame is fixed-size, except the frame_data. The fixed overhead is 16 + 2 + 4 + 1 = 23 bytes. Fixed-size frame metadata avoids a circular dependency with the target total data length, to simplify packing of frames with varying content length. where: channel_id is an opaque identifier for the channel. It should not be reused and is suggested to be random; however, outside of timeout rules, it is not checked for validity frame_number identifies the index of the frame within the channel frame_data_length is the length of frame_data in bytes. It is capped to 1,000,000 bytes. frame_data is a sequence of bytes belonging to the channel, logically after the bytes from the previous frames is_last is a single byte with a value of 1 if the frame is the last in the channel, 0 if there are frames in the channel. Any other value makes the frame invalid (it must be ignored by the rollup node).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Format","id":"145","title":"Frame Format"},"146":{"body":"A channel is encoded by applying a streaming compression algorithm to a list of batches: rlp_batches = []\nfor batch in batches: rlp_batches.append(batch) where: batches is the input, a sequence of batches byte-encoded as per the next section (\"Batch Encoding\") rlp_batches is the concatenation of the RLP-encoded batches channel_encoding = zlib_compress(rlp_batches) where zlib_compress is the ZLIB algorithm (as specified in RFC-1950 ) with no dictionary. The Fjord upgrade introduces an additional versioned channel encoding format to support alternate compression algorithms. When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL (defined in the Protocol Parameters table ), in order to avoid \"zip-bomb\" types of attack (where a small compressed input decompresses to a humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained only the first MAX_RLP_BYTES_PER_CHANNEL decompressed bytes. The limit is set on RLP decoding, so all batches that can be decoded in MAX_RLP_BYTES_PER_CHANNEL will be accepted even if the size of the channel is greater than MAX_RLP_BYTES_PER_CHANNEL. The exact requirement is that length(input) <= MAX_RLP_BYTES_PER_CHANNEL. While the above pseudocode implies that all batches are known in advance, it is possible to perform streaming compression and decompression of RLP-encoded batches. This means it is possible to start including channel frames in a batcher transaction before we know how many batches (and how many frames) the channel will contain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Format","id":"146","title":"Channel Format"},"147":{"body":"Recall that a batch contains a list of transactions to be included in a specific L2 block. A batch is encoded as batch_version ++ content, where content depends on the batch_version. Prior to the Delta upgrade, batches all have batch_version 0 and are encoded as described below. batch_version content 0 rlp_encode([parent_hash, epoch_number, epoch_hash, timestamp, transaction_list]) where: batch_version is a single byte, prefixed before the RLP contents, alike to transaction typing. rlp_encode is a function that encodes a batch according to the RLP format , and [x, y, z] denotes a list containing items x, y and z parent_hash is the block hash of the previous L2 block epoch_number and epoch_hash are the number and hash of the L1 block corresponding to the sequencing epoch of the L2 block timestamp is the timestamp of the L2 block transaction_list is an RLP-encoded list of EIP-2718 encoded transactions. The Delta upgrade introduced an additional batch type, span batches . Unknown versions make the batch invalid (it must be ignored by the rollup node), as do malformed contents. The epoch_number and the timestamp must also respect the constraints listed in the Batch Queue section, otherwise the batch is considered invalid and will be ignored.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Format","id":"147","title":"Batch Format"},"148":{"body":"The above primarily describes the general encodings used in L2 chain derivation, primarily how batches are encoded within batcher transactions . This section describes how the L2 chain is produced from the L1 batches using a pipeline architecture. A verifier may implement this differently, but must be semantically equivalent to not diverge from the L2 chain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Architecture","id":"148","title":"Architecture"},"149":{"body":"Our architecture decomposes the derivation process into a pipeline made up of the following stages: L1 Traversal L1 Retrieval Frame Queue Channel Bank Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue The data flows from the start (outer) of the pipeline towards the end (inner). From the innermost stage the data is pulled from the outermost stage. However, data is processed in reverse order. Meaning that if there is any data to be processed in the last stage, it will be processed first. Processing proceeds in \"steps\" that can be taken at each stage. We try to take as many steps as possible in the last (most inner) stage before taking any steps in its outer stage, etc. This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing the derivation pipeline. Each stage can maintain its own inner state as necessary. In particular, each stage maintains a L1 block reference (number + hash) to the latest L1 block such that all data originating from previous blocks has been fully processed, and the data from that block is being or has been processed. This allows the innermost stage to account for finalization of the L1 data-availability used to produce the L2 chain, to reflect in the L2 chain forkchoice when the L2 chain inputs become irreversible. Let's briefly describe each stage of the pipeline.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Pipeline","id":"149","title":"L2 Chain Derivation Pipeline"},"15":{"body":"Users are the general class of network participants who: Submit transactions through a Sequencer or by interacting with contracts on Ethereum. Query transaction data from interfaces operated by verifiers.","breadcrumbs":"Background » Users","id":"15","title":"Users"},"150":{"body":"In the L1 Traversal stage, we simply read the header of the next L1 block. In normal operations, these will be new L1 blocks as they get created, though we can also read old blocks while syncing, or in case of an L1 re-org . Upon traversal of the L1 block, the system configuration copy used by the L1 retrieval stage is updated, such that the batch-sender authentication is always accurate to the exact L1 block that is read by the stage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Traversal","id":"150","title":"L1 Traversal"},"151":{"body":"In the L1 Retrieval stage, we read the block we get from the outer stage (L1 traversal), and extract data from its batcher transactions . A batcher transaction is one with the following properties: The to field is equal to the configured batcher inbox address. The sender, as recovered from the transaction signature (v, r, and s), is the batcher address loaded from the system config matching the L1 block of the data. Each batcher transaction is versioned and contains a series of channel frames to be read by the Frame Queue, see Batch Submission Wire Format . Each batcher transaction in the block is processed in the order they appear in the block by passing its calldata on to the next phase.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Retrieval","id":"151","title":"L1 Retrieval"},"152":{"body":"The Frame Queue buffers one data-transaction at a time, decoded into channel frames , to be consumed by the next stage. See Batcher transaction format and Frame format specifications.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Queue","id":"152","title":"Frame Queue"},"153":{"body":"The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1 retrieval stage. A step in the channel bank stage tries to read data from channels that are \"ready\". Channels are currently fully buffered until read or dropped, streaming channels may be supported in a future version of the ChannelBank. To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels. Channels are recorded in FIFO order in a structure called the channel queue . A channel is added to the channel queue the first time a frame belonging to the channel is seen. Pruning After successfully inserting a new frame, the ChannelBank is pruned: channels are dropped in FIFO order, until total_size <= MAX_CHANNEL_BANK_SIZE, where: total_size is the sum of the sizes of each channel, which is the sum of all buffered frame data of the channel, with an additional frame-overhead of 200 bytes per frame. MAX_CHANNEL_BANK_SIZE is a protocol constant defined in the Protocol Parameters table . Timeouts The L1 origin that the channel was opened in is tracked with the channel as channel.open_l1_block, and determines the maximum span of L1 blocks that the channel data is retained for, before being pruned. A channel is timed out if: current_l1_block.number > channel.open_l1_block.number + CHANNEL_TIMEOUT, where: current_l1_block is the L1 origin that the stage is currently traversing. CHANNEL_TIMEOUT is a rollup-configurable, expressed in number of L1 blocks. New frames for timed-out channels are dropped instead of buffered. Reading Upon reading, while the first opened channel is timed-out, remove it from the channel-bank. Prior to the Canyon network upgrade, once the first opened channel, if any, is not timed-out and is ready, then it is read and removed from the channel-bank. After the Canyon network upgrade, the entire channel bank is scanned in FIFO order (by open time) & the first ready (i.e. not timed-out) channel will be returned. The canyon behavior will activate when frames from a L1 block whose timestamp is greater than or equal to the canyon time first enter the channel queue. A channel is ready if: The channel is closed The channel has a contiguous sequence of frames until the closing frame If no channel is ready, the next frame is read and ingested into the channel bank. Loading frames When a channel ID referenced by a frame is not already present in the Channel Bank, a new channel is opened, tagged with the current L1 block, and appended to the channel-queue. Frame insertion conditions: New frames matching timed-out channels that have not yet been pruned from the channel-bank are dropped. Duplicate frames (by frame number) for frames that have not been pruned from the channel-bank are dropped. Duplicate closes (new frame is_last == 1, but the channel has already seen a closing frame and has not yet been pruned from the channel-bank) are dropped. If a frame is closing (is_last == 1) any existing higher-numbered frames are removed from the channel. Note that while this allows channel IDs to be reused once they have been pruned from the channel-bank, it is recommended that batcher implementations use unique channel IDs.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Bank","id":"153","title":"Channel Bank"},"154":{"body":"In this stage, we decompress the channel we pull from the last stage, and then parse batches from the decompressed byte stream. See Channel Format and Batch Format for decompression and decoding specification.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Reader (Batch Decoding)","id":"154","title":"Channel Reader (Batch Decoding)"},"155":{"body":"During the Batch Buffering stage, we reorder batches by their timestamps. If batches are missing for some time slots and a valid batch with a higher timestamp exists, this stage also generates empty batches to fill the gaps. Batches are pushed to the next stage whenever there is one sequential batch directly following the timestamp of the current safe L2 head (the last block that can be derived from the canonical L1 chain). The parent hash of the batch must also match the hash of the current safe L2 head. Note that the presence of any gaps in the batches derived from L1 means that this stage will need to buffer for a whole sequencing window before it can generate empty batches (because the missing batch(es) could have data in the last L1 block of the window in the worst case). A batch can have 4 different forms of validity: drop: the batch is invalid, and will always be in the future, unless we reorg. It can be removed from the buffer. accept: the batch is valid and should be processed. undecided: we are lacking L1 information until we can proceed batch filtering. future: the batch may be valid, but cannot be processed yet and should be checked again later. The batches are processed in order of the inclusion on L1: if multiple batches can be accept-ed the first is applied. An implementation can defer future batches a later derivation step to reduce validation work. The batches validity is derived as follows: Definitions: batch as defined in the Batch format section . epoch = safe_l2_head.l1_origin a L1 origin coupled to the batch, with properties: number (L1 block number), hash (L1 block hash), and timestamp (L1 block timestamp). inclusion_block_number is the L1 block number when batch was first fully derived, i.e. decoded and output by the previous stage. next_timestamp = safe_l2_head.timestamp + block_time is the expected L2 timestamp the next batch should have, see block time information . next_epoch may not be known yet, but would be the L1 block after epoch if available. batch_origin is either epoch or next_epoch, depending on validation. Note that processing of a batch can be deferred until batch.timestamp <= next_timestamp, since future batches will have to be retained anyway. Rules, in validation order: batch.timestamp > next_timestamp -> future: i.e. the batch must be ready to process. batch.timestamp < next_timestamp -> drop: i.e. the batch must not be too old. batch.parent_hash != safe_l2_head.hash -> drop: i.e. the parent hash must be equal to the L2 safe head block hash. batch.epoch_num + sequence_window_size < inclusion_block_number -> drop: i.e. the batch must be included timely. batch.epoch_num < epoch.number -> drop: i.e. the batch origin is not older than that of the L2 safe head. batch.epoch_num == epoch.number: define batch_origin as epoch. batch.epoch_num == epoch.number+1: If next_epoch is not known -> undecided: i.e. a batch that changes the L1 origin cannot be processed until we have the L1 origin data. If known, then define batch_origin as next_epoch batch.epoch_num > epoch.number+1 -> drop: i.e. the L1 origin cannot change by more than one L1 block per L2 block. batch.epoch_hash != batch_origin.hash -> drop: i.e. a batch must reference a canonical L1 origin, to prevent batches from being replayed onto unexpected L1 chains. batch.timestamp < batch_origin.time -> drop: enforce the min L2 timestamp rule. batch.timestamp > batch_origin.time + max_sequencer_drift: enforce the L2 timestamp drift rule, but with exceptions to preserve above min L2 timestamp invariant: len(batch.transactions) == 0: epoch.number == batch.epoch_num: this implies the batch does not already advance the L1 origin, and must thus be checked against next_epoch. If next_epoch is not known -> undecided: without the next L1 origin we cannot yet determine if time invariant could have been kept. If batch.timestamp >= next_epoch.time -> drop: the batch could have adopted the next L1 origin without breaking the L2 time >= L1 time invariant. len(batch.transactions) > 0: -> drop: when exceeding the sequencer time drift, never allow the sequencer to include transactions. batch.transactions: drop if the batch.transactions list contains a transaction that is invalid or derived by other means exclusively: any transaction that is empty (zero length byte string) any deposited transactions (identified by the transaction type prefix byte) If no batch can be accept-ed, and the stage has completed buffering of all batches that can fully be read from the L1 block at height epoch.number + sequence_window_size, and the next_epoch is available, then an empty batch can be derived with the following properties: parent_hash = safe_l2_head.hash timestamp = next_timestamp transactions is empty, i.e. no sequencer transactions. Deposited transactions may be added in the next stage. If next_timestamp < next_epoch.time: the current L1 origin is repeated, to preserve the L2 time invariant. epoch_num = epoch.number epoch_hash = epoch.hash If the batch is the first batch of the epoch, that epoch is used instead of advancing the epoch to ensure that there is at least one L2 block per epoch. epoch_num = epoch.number epoch_hash = epoch.hash Otherwise, epoch_num = next_epoch.number epoch_hash = next_epoch.hash","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Queue","id":"155","title":"Batch Queue"},"156":{"body":"In the Payload Attributes Derivation stage, we convert the batches we get from the previous stage into instances of the PayloadAttributes structure. Such a structure encodes the transactions that need to figure into a block, as well as other block inputs (timestamp, fee recipient, etc). Payload attributes derivation is detailed in the section Deriving Payload Attributes section below. This stage maintains its own copy of the system configuration , independent of the L1 retrieval stage. The system configuration is updated with L1 log events whenever the L1 epoch referenced by the batch input changes.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Payload Attributes Derivation","id":"156","title":"Payload Attributes Derivation"},"157":{"body":"In the Engine Queue stage, the previously derived PayloadAttributes structures are buffered and sent to the execution engine to be executed and converted into a proper L2 block. The stage maintains references to three L2 blocks: The finalized L2 head : everything up to and including this block can be fully derived from the finalized (i.e. canonical and forever irreversible) part of the L1 chain. The safe L2 head : everything up to and including this block can be fully derived from the currently canonical L1 chain. The unsafe L2 head : blocks between the safe and unsafe heads are unsafe blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer mode) or from unsafe sync to the sequencer (in validator mode). This is also known as the \"latest\" head. Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references from which L1 blocks each was derived. This history does not have to be complete, but enables later L1 finality signals to be translated into L2 finality. Engine API usage To interact with the engine, the execution engine API is used, with the following JSON-RPC methods: Bedrock, Canyon, Delta: API Usage engine_forkchoiceUpdatedV2 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV2 — retrieves a previously requested execution payload build. engine_newPayloadV2 — executes an execution payload to create a block. Ecotone: API Usage engine_forkchoiceUpdatedV3 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV3 — retrieves a previously requested execution payload build. engine_newPayload engine_newPayloadV2 — executes a Bedrock/Canyon/Delta execution payload to create a block. engine_newPayloadV3 — executes an Ecotone execution payload to create a block. The current version of op-node uses the v3 Engine API RPC methods as well as engine_newPayloadV2, due to engine_newPayloadV3 only supporting Ecotone execution payloads. Both engine_forkchoiceUpdatedV3 and engine_getPayloadV3 are backwards compatible with Bedrock, Canyon & Delta payloads. Prior versions of op-node used v2 and v1 methods. The execution payload is an object of type ExecutionPayloadV3 . The ExecutionPayload has the following requirements: Bedrock The withdrawals field MUST be nil The blob gas used field MUST be nil The blob gas limit field MUST be nil Canyon, Delta The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be nil The blob gas limit field MUST be nil Ecotone The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be 0 The blob gas limit field MUST be 0 Forkchoice synchronization If there are any forkchoice updates to be applied, before additional inputs are derived or processed, then these are applied to the engine first. This synchronization may happen when: A L1 finality signal finalizes one or more L2 blocks: updating the \"finalized\" L2 block. A successful consolidation of unsafe L2 blocks: updating the \"safe\" L2 block. The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state. The new forkchoice state is applied by calling fork choice updated on the engine API. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. L1-consolidation: payload attributes matching If the unsafe head is ahead of the safe head, then consolidation is attempted, verifying that existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data. During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If the payload attributes match this oldest unsafe L2 block, then that block can be considered \"safe\" and becomes the new safe head. The following fields of the derived L2 payload attributes are checked for equality with the L2 block: Bedrock, Canyon, Delta, Ecotone Blocks parent_hash timestamp randao fee_recipient transactions_list (first length, then equality of each of the encoded transactions, including deposits) gas_limit Canyon, Delta, Ecotone Blocks withdrawals (first presence, then length, then equality of each of the encoded withdrawals) Ecotone Blocks parent_beacon_block_root If consolidation succeeds, the forkchoice change will synchronize as described in the section above. If consolidation fails, the L2 payload attributes will be processed immediately as described in the section below. The payload attributes are chosen in favor of the previous unsafe L2 block, creating an L2 chain reorg on top of the current safe block. Immediately processing the new alternative attributes enables execution engines like go-ethereum to enact the change, as linear rewinds of the tip of the chain may not be supported. L1-sync: payload attributes processing If the safe and unsafe L2 heads are identical (whether because of failed consolidation or not), we send the L2 payload attributes to the execution engine to be constructed into a proper L2 block. This L2 block will then become both the new L2 safe and unsafe head. If a payload attributes created from a batch cannot be inserted into the chain because of a validation error (i.e. there was an invalid transaction or state transition in the block) the batch should be dropped & the safe head should not be advanced. The engine queue will attempt to use the next batch for that timestamp from the batch queue. If no valid batch is found, the rollup node will create a deposit only batch which should always pass validation because deposits are always valid. Interaction with the execution engine via the execution engine API is detailed in the Communication with the Execution Engine section. The payload attributes are then processed with a sequence of: Engine: Fork choice updated with current forkchoice state of the stage, and the attributes to start block building. Non-deterministic sources, like the tx-pool, must be disabled to reconstruct the expected block. Engine: Get Payload to retrieve the payload, by the payload-ID in the result of the previous step. Engine: New Payload to import the new payload into the execution engine. Engine: Fork Choice Updated to make the new payload canonical, now with a change of both safe and unsafe fields to refer to the payload, and no payload attributes. Engine API Error handling: On RPC-type errors the payload attributes processing should be re-attempted in a future step. On payload processing errors the attributes must be dropped, and the forkchoice state must be left unchanged. Eventually the derivation pipeline will produce alternative payload attributes, with or without batches. If the payload attributes only contained deposits, then it is a critical derivation error if these are invalid. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. Processing unsafe payload attributes If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as an \"unsafe\" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the user to see the head of the L2 chain faster than the L1 may confirm the L2 batches. To process unsafe payloads, the payload must: Have a block number higher than the current safe L2 head. The safe L2 head may only be reorged out due to L1 reorgs. Have a parent blockhash that matches the current unsafe L2 head. This prevents the execution engine individually syncing a larger gap in the unsafe L2 chain. This prevents unsafe L2 blocks from reorging other previously validated L2 blocks. This check may change in the future versions to adopt e.g. the L1 snap-sync protocol. The payload is then processed with a sequence of: Bedrock/Canyon/Delta Payloads engine_newPayloadV2: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV2: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Ecotone Payloads engine_newPayloadV3: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV3: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Engine API Error handling: On RPC-type errors the payload processing should be re-attempted in a future step. On payload processing errors the payload must be dropped, and not be marked as canonical. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Engine Queue","id":"157","title":"Engine Queue"},"158":{"body":"It is possible to reset the pipeline, for instance if we detect an L1 reorg (reorganization) . This enables the rollup node to handle L1 chain reorg events. Resetting will recover the pipeline into a state that produces the same outputs as a full L2 derivation process, but starting from an existing L2 chain that is traversed back just enough to reconcile with the current L1 chain. Note that this algorithm covers several important use-cases: Initialize the pipeline without starting from 0, e.g. when the rollup node restarts with an existing engine instance. Recover the pipeline if it becomes inconsistent with the execution engine chain, e.g. when the engine syncs/changes. Recover the pipeline when the L1 chain reorganizes, e.g. a late L1 block is orphaned, or a larger attestation failure. Initialize the pipeline to derive a disputed L2 block with prior L1 and L2 history inside a fault-proof program. Handling these cases also means a node can be configured to eagerly sync L1 data with 0 confirmations, as it can undo the changes if the L1 later does recognize the data as canonical, enabling safe low-latency usage. The Engine Queue is first reset, to determine the L1 and L2 starting points to continue derivation from. After this, the other stages are reset independent of each other. Finding the sync starting point To find the starting point, there are several steps, relative to the head of the chain traversing back: Find the current L2 forkchoice state If no finalized block can be found, start at the Bedrock genesis block. If no safe block can be found, fallback to the finalized block. The unsafe block should always be available and consistent with the above (it may not be in rare engine-corruption recovery cases, this is being reviewed). Find the first L2 block with plausible L1 reference to be the new unsafe starting point, starting from previous unsafe, back to finalized and no further. Plausible iff: the L1 origin of the L2 block is known and canonical, or unknown and has a block-number ahead of L1. Find the first L2 block with an L1 reference older than the sequencing window, to be the new safe starting point, starting at the above plausible unsafe head, back to finalized and no further. If at any point the L1 origin is known but not canonical, the unsafe head is revised to parent of the current. The highest L2 block with known canonical L1 origin is remembered as highest. If at any point the L1 origin in the block is corrupt w.r.t. derivation rules, then error. Corruption includes: Inconsistent L1 origin block number or parent-hash with parent L1 origin Inconsistent L1 sequence number (always changes to 0 for a L1 origin change, or increments by 1 if not) If the L1 origin of the L2 block n is older than the L1 origin of highest by more than a sequence window, and n.sequence_number == 0, then the parent L2 block of n will be the safe starting point. The finalized L2 block persists as the finalized starting point. Find the first L2 block with an L1 reference older than the channel-timeout The L1 origin referenced by this block which we call l2base will be the base for the L2 pipeline derivation: By starting here, the stages can buffer any necessary data, while dropping incomplete derivation outputs until L1 traversal has caught up with the actual L2 safe head. While traversing back the L2 chain, an implementation may sanity-check that the starting point is never set too far back compared to the existing forkchoice state, to avoid an intensive reorg because of misconfiguration. Implementers note: step 1-4 are known as FindL2Heads. Step 5 is currently part of the Engine Queue reset. This may change to isolate the starting-point search from the bare reset logic. Resetting derivation stages L1 Traversal: start at L1 base as first block to be pulled by next stage. L1 Retrieval: empty previous data, and fetch the base L1 data, or defer the fetching work to a later pipeline step. Frame Queue: empty the queue. Channel Bank: empty the channel bank. Channel Reader: reset any batch decoding state. Batch Queue: empty the batch queue, use base as initial L1 point of reference. Payload Attributes Derivation: empty any batch/attributes state. Engine Queue: Initialize L2 forkchoice state with syncing start point state. (finalized/safe/unsafe) Initialize the L1 point of reference of the stage to base. Require a forkchoice update as first task Reset any finality data Where necessary, stages starting at base can initialize their system-config from data encoded in the l2base block. About reorgs Post-Merge Note that post- merge , the depth of reorgs will be bounded by the L1 finality delay (2 L1 beacon epochs, or approximately 13 minutes, unless more than 1/3 of the network consistently disagrees). New L1 blocks may be finalized every L1 beacon epoch (approximately 6.4 minutes), and depending on these finality-signals and batch-inclusion, the derived L2 chain will become irreversible as well. Note that this form of finalization only affects inputs, and nodes can then subjectively say the chain is irreversible, by reproducing the chain from these irreversible inputs and the set protocol rules and parameters. This is however completely unrelated to the outputs posted on L1, which require a form of proof like a fault-proof or zk-proof to finalize. Optimistic-rollup outputs like withdrawals on L1 are only labeled \"finalized\" after passing a week without dispute (fault proof challenge window), a name-collision with the proof-of-stake finalization.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Resetting the Pipeline","id":"158","title":"Resetting the Pipeline"},"159":{"body":"For every L2 block derived from L1 data, we need to build payload attributes , represented by an expanded version of the PayloadAttributesV2 object, which includes additional transactions and noTxPool fields. This process happens during the payloads-attributes queue ran by a verifier node, as well as during block-production ran by a sequencer node (the sequencer may enable the tx-pool usage if the transactions are batch-submitted).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving Payload Attributes","id":"159","title":"Deriving Payload Attributes"},"16":{"body":"Sequencers fill the role of the block producer on an OP Stack chain. Chains may have a single Sequencer or may choose to utilize some consensus protocol that coordinates multiple Sequencers. The OP Stack currently officially only supports a single active Sequencer at any given time. In general, specifications may use the term \"the Sequencer\" as a stand-in for either a single Sequencer or a consensus protocol of multiple Sequencers. The Sequencer: Accepts transactions directly from Users. Observes \"deposit\" transactions generated on Ethereum. Consolidates both transaction streams into ordered L2 blocks. Submits information to L1 that is sufficient to fully reproduce those L2 blocks. Provides real-time access to pending L2 blocks that have not yet been confirmed on L1. The Sequencer serves an important role for the operation of an L2 chain but is not a trusted actor. The Sequencer is generally responsible for improving the user experience by ordering transactions much more quickly and cheaply than would currently be possible if users were to submit all transactions directly to L1.","breadcrumbs":"Background » Sequencers","id":"16","title":"Sequencers"},"160":{"body":"For each L2 block to be created by the sequencer, we start from a sequencer batch matching the target L2 block number. This could potentially be an empty auto-generated batch, if the L1 chain did not include a batch for the target L2 block number. Remember that the batch includes a sequencing epoch number, an L2 timestamp, and a transaction list. This block is part of a sequencing epoch , whose number matches that of an L1 block (its L1 origin ). This L1 block is used to derive L1 attributes and (for the first L2 block in the epoch) user deposits. Therefore, a PayloadAttributesV2 object must include the following transactions: one or more deposited transactions , of two kinds: a single L1 attributes deposited transaction , derived from the L1 origin. for the first L2 block in the epoch, zero or more user-deposited transactions , derived from the receipts of the L1 origin. zero or more network upgrade automation transactions : special transactions to perform network upgrades. zero or more sequenced transactions : regular transactions signed by L2 users, included in the sequencer batch. Transactions must appear in this order in the payload attributes. The L1 attributes are read from the L1 block header, while deposits are read from the L1 block's receipts . Refer to the deposit contract specification for details on how deposits are encoded as log entries.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving the Transaction List","id":"160","title":"Deriving the Transaction List"},"161":{"body":"Some network upgrades require automated contract changes or deployments at specific blocks. To automate these, without adding persistent changes to the execution-layer, special transactions may be inserted as part of the derivation process. Ecotone The Ecotone hardfork activation block contains the following transactions, in this order: L1 Attributes Transaction, using the pre-Ecotone setL1BlockValues User deposits from L1 Network Upgrade Transactions L1Block deployment GasPriceOracle deployment Update L1Block Proxy ERC-1967 Implementation Slot Update GasPriceOracle Proxy ERC-1967 Implementation Slot GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) To not modify or interrupt the system behavior around gas computation, this block will not include any sequenced transactions by setting noTxPool: true. L1Block Deployment The L1Block contract is upgraded to process the new Ecotone L1-data-fee parameters and L1 blob base-fee. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000000 to: null mint: 0 value: 0 gasLimit: 375,000 data: 0x60806040523480156100105... ( full bytecode ) sourceHash: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Deployment\" This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000000\nComputed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Deployment\"))\n# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json This transaction MUST deploy a contract with the following code hash 0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd. GasPriceOracle Deployment The GasPriceOracle contract is upgraded to support the new Ecotone L1-data-fee parameters. Post fork this contract will use the blob base fee to compute the gas price for L1-data-fee transactions. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000001 to: null, mint: 0 value: 0 gasLimit: 1,000,000 data: 0x60806040523480156100... ( full bytecode ) sourceHash: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Deployment\" This results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000001\nComputed Address: 0xb528D11cC114E026F138fE568744c6D45ce6Da7A Verify sourceHash: ❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Deployment\"))\n# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json This transaction MUST deploy a contract with the following code hash 0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5. L1Block Proxy Update This transaction updates the L1Block Proxy ERC-1967 implementation slot to point to the new L1Block deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x4200000000000000000000000000000000000015 (L1Block Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff sourceHash: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)\n0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Proxy Update\"))\n# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc GasPriceOracle Proxy Update This transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a sourceHash: 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: Gas Price Oracle Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)\n0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Proxy Update\"))\n# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a GasPriceOracle Enable Ecotone This transaction informs the GasPriceOracle to start using the Ecotone gas calculation formula. A deposit transaction is derived with the following attributes: from: 0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 (Depositer Account) to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 80,000 data: 0x22b90ab3 sourceHash: 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Set Ecotone\" Verify data: cast sig \"setEcotone()\"\n0x22b90ab3 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Set Ecotone\"))\n# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93 Beacon block roots contract deployment (EIP-4788) EIP-4788 introduces a \"Beacon block roots\" contract, that processes and exposes the beacon-block-root values. at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02. For deployment, EIP-4788 defines a pre- EIP-155 legacy transaction, sent from a key that is derived such that the transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code. However, this type of transaction requires manual deployment and gas-payments. And since the processing is an integral part of the chain processing, and has to be repeated for every OP-Stack chain, the deployment is approached differently here. Some chains may already have a user-submitted instance of the EIP-4788 transaction. This is cryptographically guaranteed to be correct, but may result in the upgrade transaction deploying a second contract, with the next nonce. The result of this deployment can be ignored. A Deposit transaction is derived with the following attributes: from: 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875, as specified in the EIP. to: null mint: 0 value: 0 gasLimit: 0x3d090, as specified in the EIP. isCreation: true data: 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500 isSystemTx: false, as per the Regolith upgrade, even the system-generated transactions spend gas. sourceHash: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c, computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: beacon block roots contract deployment\" The contract address upon deployment is computed as rlp([sender, nonce]), which will equal: BEACON_ROOTS_ADDRESS if deployed a different address (0xE3aE1Ae551eeEda337c0BfF6C4c7cbA98dce353B) if nonce = 1: when a user already submitted the EIP transaction before the upgrade. Verify BEACON_ROOTS_ADDRESS: cast compute-address --nonce=0 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875\n# Computed Address: 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: beacon block roots contract deployment\"))\n# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Network upgrade automation transactions","id":"161","title":"Network upgrade automation transactions"},"162":{"body":"After deriving the transactions list, the rollup node constructs a PayloadAttributesV2 as follows: timestamp is set to the batch's timestamp. random is set to the prev_randao L1 block attribute. suggestedFeeRecipient is set to the Sequencer Fee Vault address. See Fee Vaults specification. transactions is the array of the derived transactions: deposited transactions and sequenced transactions, all encoded with EIP-2718 . noTxPool is set to true, to use the exact above transactions list when constructing the block. gasLimit is set to the current gasLimit value in the system configuration of this payload. withdrawals is set to nil prior to Canyon and an empty array after Canyon","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Building Individual Payload Attributes","id":"162","title":"Building Individual Payload Attributes"},"163":{"body":"Table of Contents Overview","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Batch Submitter","id":"163","title":"Batch Submitter"},"164":{"body":"The batch submitter, also referred to as the batcher, is the entity submitting the L2 sequencer data to L1, to make it available for verifiers. The format of the data transactions is defined in the derivation spec : the data is constructed from L2 blocks in the reverse order as it is derived from data into L2 blocks. The timing, operation and transaction signing is implementation-specific: any data can be submitted at any time, but only the data that matches the derivation spec rules will be valid from the verifier perspective. The most minimal batcher implementation can be defined as a loop of the following operations: See if the unsafe L2 block number is past the safe block number: unsafe data needs to be submitted. Iterate over all unsafe L2 blocks, skip any that were previously submitted. Open a channel, buffer all the L2 block data to be submitted, while applying the encoding and compression as defined in the derivation spec . Pull frames from the channel to fill data transactions with, until the channel is empty. Submit the data transactions to L1 The L2 view of safe/unsafe does not instantly update after data is submitted, nor when it gets confirmed on L1, so special care may have to be taken to not duplicate data submissions.","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Overview","id":"164","title":"Overview"},"165":{"body":"Table of Contents Overview Pre-image Oracle Pre-image key types Type 0: Zero key Type 1: Local key Type 2: Global keccak256 key Type 3: Global generic key Type 4: Global SHA2-256 key Type 5: Global EIP-4844 Point-evaluation key Type 6: Global Precompile key Type 7-128: reserved range Type 129-255: application usage Bootstrapping Hinting Pre-image communication Fault Proof Program Prologue Main content Epilogue Pre-image hinting routes l1-block-header l1-transactions l1-receipts l1-precompile l2-block-header l2-transactions l2-code l2-state-node l2-output Precompile Accelerators Fault Proof VM Fault Proof Interactive Dispute Game","breadcrumbs":"OP Stack Protocol » Fault Proof » Fault Proof","id":"165","title":"Fault Proof"},"166":{"body":"A fault proof, also known as fraud proof or interactive game, consists of 3 components: Program : given a commitment to all rollup inputs (L1 data) and the dispute, verify the dispute statelessly. VM : given a stateless program and its inputs, trace any instruction step, and prove it on L1. Interactive Dispute Game : bisect a dispute down to a single instruction, and resolve the base-case using the VM. Each of these 3 components may have different implementations, which can be combined into different proof stacks, and contribute to proof diversity when resolving a dispute. \"Stateless execution\" of the program, and its individual instructions, refers to reproducing the exact same computation by authenticating the inputs with a Pre-image Oracle . Diagram of Program and VM architecture","breadcrumbs":"OP Stack Protocol » Fault Proof » Overview","id":"166","title":"Overview"},"167":{"body":"The pre-image oracle is the only form of communication between the Program (in the Client role) and the VM (in the Server role). The program uses the pre-image oracle to query any input data that is understood to be available to the user: The initial inputs to bootstrap the program. See Bootstrapping . External data not already part of the program code. See Pre-image hinting routes . The communication happens over a simple request-response wire protocol, see Pre-image communication .","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image Oracle","id":"167","title":"Pre-image Oracle"},"168":{"body":"Pre-images are identified by a bytes32 type-prefixed key: The first byte identifies the type of request. The remaining 31 bytes identify the pre-image key. Type 0: Zero key The zero prefix is illegal. This ensures all pre-image keys are non-zero, enabling storage lookup optimizations and avoiding easy mistakes with invalid zeroed keys in the EVM. Type 1: Local key Information specific to the dispute: the remainder of the key may be an index, a string, a hash, etc. Only the contract(s) managing this dispute instance may serve the value for this key: it is localized and context-dependent. This type of key is used for program bootstrapping, to identify the initial input arguments by index or name. Type 2: Global keccak256 key This type of key uses a global pre-image store contract, and is fully context-independent and permissionless. I.e. every key must have a single unique value, regardless of chain history or time. Using a global store reduces duplicate pre-image registration work, and avoids unnecessary contract redeployments per dispute. This global store contract should be non-upgradeable. Since keccak256 is a safe 32-byte hash input, the first byte is overwritten with a 2 to derive the key, while keeping the rest of the key \"readable\" (matching the original hash). Type 3: Global generic key Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments. This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:], where: x is a bytes32, which can be a hash of an arbitrary-length type of cryptographically secure commitment. sender is a bytes32 identifying the pre-image inserter address (left-padded to 32 bytes) This global store contract should be non-upgradeable. The global contract is permissionless: users can standardize around external contracts that verify pre-images (i.e. a specific sender will always be trusted for a specific kind of pre-image). The external contract verifies the pre-image before inserting it into the global store for usage by all fault proof VMs without requiring the VM or global store contract to be changed. Users may standardize around upgradeable external pre-image contracts, in case the implementation of the verification of the pre-image is expected to change. The store update function is update(x bytes32, offset uint64, span uint8, value bytes32): x is the bytes32 x that the pre-image key is computed with. Only part of the pre-image, starting at offset, and up to (incl.) 32 bytes span can be inserted at a time. Pre-images may have an undefined length (e.g. a stream), we only need to know how many bytes of value are usable. The key and offset will be hashed together to uniquely store the value and span, for later pre-image serving. This enables fault proof programs to adopt any new pre-image schemes without VM update or contract redeployment. It is up to the user to index the special pre-image values by this key scheme, as there is no way to revert it to the original commitment without knowing said commitment or value. Type 4: Global SHA2-256 key A SHA-256 pre-image. Key: the SHA-256 hash, with the first byte overwritten with the type byte: 4 ++ sha256(data)[1:]. Type 5: Global EIP-4844 Point-evaluation key An EIP-4844 point-evaluation. In an EIP-4844 blob, 4096 field elements represent the blob data. It verifies p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof. The value y is the pre-image. The value z is part of the key; the index of the point within the blob. The commitment is part of the key. Each element is proven with a point-evaluation. Key: 5 ++ keccak256(commitment ++ z)[1:], where: 5 is the type byte ++ is concatenation commitment is a bytes48, representing the KZG commitment. z is a big-endian uint256 Type 6: Global Precompile key A precompile result. It maps directly to precompiles on Ethereum. This preimage key can be used to avoid running expensive precompile operations in the program. Key: 6 ++ keccak256(precompile ++ input)[1:], where: 6 is the type byte ++ is concatenation precompile is the 20-byte address of the precompile contract input is the input to the precompile contract The result is identical to that of a call to the precompile contract, prefixed with a revert indicator: reverted ++ precompile_result. reverted is a 1-byte indicator with a 0 value if the precompile reverts for the given input, otherwise it's 1. Type 7-128: reserved range Range start and end both inclusive. This range of key types is reserved for future usage by the core protocol. E.g. version changes, contract migrations, chain-data, additional core features, etc. 128 specifically (1000 0000 in binary) is reserved for key-type length-extension (reducing the content part to 30 or less key bytes), if the need arises. Type 129-255: application usage This range of key types may be used by forks or customized versions of the fault proof protocol.","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image key types","id":"168","title":"Pre-image key types"},"169":{"body":"Initial inputs are deterministic, but not necessarily singular or global: there may be multiple different disputes at the same time, each with its own disputed claims and L1 context. To bootstrap, the program requests the initial inputs from the VM, using pre-image key type 1. The VM is aware of the external context, and maps requested pre-image keys based on their type, i.e. a local lookup for type 1, or global one for 2, and optionally support other key-types.","breadcrumbs":"OP Stack Protocol » Fault Proof » Bootstrapping","id":"169","title":"Bootstrapping"},"17":{"body":"Verifiers download and execute the L2 state transition function independently of the Sequencer. Verifiers help to maintain the integrity of the network and serve blockchain data to Users. Verifiers generally: Download rollup data from L1 and the Sequencer. Use rollup data to execute the L2 state transition function. Serve rollup data and computed L2 state information to Users. Verifiers can also act as Proposers and/or Challengers who: Submit assertions about the state of the L2 to a smart contract on L1. Validate assertions made by other participants. Dispute invalid assertions made by other participants.","breadcrumbs":"Background » Verifiers","id":"17","title":"Verifiers"},"170":{"body":"There is one more form of optional communication between client and server: pre-image hinting. Hinting is optional, and is a no-op in a L1 VM implementation. The hint itself comes at very low cost onchain: the hint can be a single write sys-call, which is instant as the memory to write as hint does not actually need to be loaded as part of the onchain proof. Hinting allows the program, when generating a proof offchain, to instruct the VM what data it is interested in. The VM can choose to execute the requested hint at any time: either locally (for standard requests), or in a modular form by redirecting the hint to tooling that may come with the VM program. Hints do not have to be executed directly: they may first just be logged to show the intents of the program, and the latest hint may be buffered for lazy execution, or dropped entirely when in read-only mode (like onchain). When the pre-image oracle serves a request, and the request cannot be served from an existing collection of pre-images (e.g. a local pre-image cache) then the VM can execute the hint to retrieve the missing pre-image(s). It is the responsibility of the program to provide sufficient hinting for every pre-image request. Some hints may have to be repeated: the VM only has to execute the last hint when handling a missing pre-image. Note that hints may produce multiple pre-images: e.g. a hint for an ethereum block with transaction list may prepare pre-images for the header, each of the transactions, and the intermediate merkle-nodes that form the transactions-list Merkle Patricia Trie. Hinting is implemented with a request-acknowledgement wire-protocol over a blocking two-way stream: := := := big-endian uint32 # length of \n := byte sequence\n := 1-byte zero value The ack informs the client that the hint has been processed. Servers may respond to hints and pre-image (see below) requests asynchronously as they are on separate streams. To avoid requesting pre-images that are not yet fetched, clients should request the pre-image only after it has observed the hint acknowledgement.","breadcrumbs":"OP Stack Protocol » Fault Proof » Hinting","id":"170","title":"Hinting"},"171":{"body":"Pre-images are communicated with a minimal wire-protocol over a blocking two-way stream. This protocol can be implemented with blocking read/write syscalls. :=
This function returns the currently configured EIP-1559 denominator.
function eip1559Denominator()(uint64)
For each FeeVault, there is a setter for its config. The arguments to the setter include -the RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork. -Each of these functions should be public and only callable by the chain governor.
public
Each function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType.
OptimismPortal.setConfig(ConfigType,bytes)
function setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork) -
function setL1FeeVaultConfig(address,uint256,WithdrawalNetwork) -
function setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork) -
The OptimismPortal is updated to emit a special system TransactionDeposited event.
TransactionDeposited
The setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig -is the single source of truth for chain operator ownership.
This function emits a TransactionDeposited event.
event TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData); -
The following fields are included:
from
to
Predeploys.L1Block
version
opaqueData
mint
value
200_000
isCreation
false
data
abi.encodeCall(L1Block.setConfig, (_type, _value))
The terms "custom gas token", "gas paying token", "native asset" and "gas paying asset" can all be used interchangeably. Note, Ether is not a custom gas token, but may be used to pay gas. More on this in Configuring the Gas Paying Token.
ETHER_TOKEN_ADDRESS
address(0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE)
address(0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001)
The OptimismPortal is updated with a new interface specifically for depositing custom tokens.
depositERC20Transaction
The depositERC20Transaction function is useful for sending custom gas tokens to L2. It is broken out into its @@ -9848,7 +9519,7 @@
The SystemConfig is the source of truth for the address of the custom gas token. It does on chain validation, stores information about the token and well as passes the information to L2.
OptimismPortal.setGasPayingToken
initialize
The L1Block contract is upgraded with a permissioned function setGasPayingToken that is used to set information about the gas paying token. The DEPOSITOR_ACCOUNT MUST be the only account that can call the setter function. This setter is differentiated from the setL1BlockValues functions because the gas paying @@ -10019,7 +9690,7 @@
setGasPayingToken
setL1BlockValues
The OptimismPortal makes calls on behalf of users. It is therefore unsafe to be able to call the address of the custom gas token itself from the OptimismPortal because it would be a simple way to approve an attacker's @@ -10287,7 +9958,7 @@
approve
The engine queue will maintain a longer buffer of L2 blocks waiting for the DA window to expire and the L1 block with the commitment to be finalized in order to signal finality.
The Data Availability Challenge contract mitigates DoS vulnerability with a payable bond requirement making challenging the availability of a commitment at least as expensive as submitting the data onchain to resolve the challenge. @@ -10387,7 +10058,7 @@
The layer one MAY be part of the dependency set if the fault proof implementation is set up to support it. It is known that it is possible but it is not known if this is going to be @@ -10603,7 +10274,7 @@
The verifier is responsible for filtering out non-canonical parts of the graph.
If there is a cycle in the dependency set, chains MUST still be able to promote unsafe blocks to safe blocks. A cycle in the dependency set happens anytime that two chains are in each other's @@ -11126,7 +10797,7 @@
The Beacon Contract implements the interface defined in EIP-1967.
The implementation address gets deduced similarly to the GasPriceOracle address in Ecotone and Fjord updates.
GasPriceOracle
0x4200000000000000000000000000000000000015
0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001
event StandardL2TokenCreated(address indexed remoteToken, address indexed localToken);
0x4200000000000000000000000000000000000010
TODO
If a user does not have ether to pay for the gas of an executing message, application layer sponsorship solutions can be created. It is possible to create an MEV incentive by paying tx.origin in the executing message. This can be done by wrapping the L2ToL2CrossDomainMessenger with a pair of relaying contracts.
tx.origin
L2ToL2CrossDomainMessenger
The latency at which a cross chain message is relayed from the moment at which it was initiated is bottlenecked by the security of the preconfirmations. An initiating transaction and a executing transaction MAY have the same timestamp, @@ -11699,7 +11370,7 @@
The design is particular to not introduce any sort of "forced inclusion" between L2s. This design space introduces risky synchrony assumptions and forces the introduction of a message queue to prevent denial of service attacks where @@ -11739,7 +11410,7 @@
No changes to the dispute game bisection are required. The only changes required are to the fault proof program itself. The insight is that the fault proof program can be a superset of the state transition function.
Notice that ERC20s that do not implement the standard can still be fungible using interop message passing using a custom bridge or implementing sendERC20 and relayERC20 on their own contracts.
sendERC20
relayERC20
Implementations of the SuperchainERC20 standard will need to implement two external functions and two events:
SuperchainERC20
__superchainMint
Mints _amount of token to address _account. It should only be callable by the SuperchainERC20Bridge
_amount
_account
SuperchainERC20Bridge
SuperchainWETH
0x4200000000000000000000000000000000000024
ETHLiquidity
0x4200000000000000000000000000000000000025
There must be sufficient gas available in the block to destroy deposit context. There's no guarantee on the minimum gas available for the second L1 attributes transaction as the block @@ -12330,7 +12001,7 @@
Since the validation of the executing message relies on a remote RPC request, this introduces a denial of service attack vector. The cost of network access is magnitudes larger than in memory validity checks. @@ -12378,8 +12049,8 @@
The OP Contracts Manager is a proxied contract using the standard Proxy.sol contract that lives in @@ -12478,7 +12149,7 @@
One of the implicit restrictions on chain ID is that deploy can only be called once per chain ID, because contract addresses are a function of chain ID. However, diff --git a/protocol/batcher.html b/protocol/batcher.html index 3b2dd42f6..b43477961 100644 --- a/protocol/batcher.html +++ b/protocol/batcher.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/bridges.html b/protocol/bridges.html index 82d8153b0..78ccebfed 100644 --- a/protocol/bridges.html +++ b/protocol/bridges.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/canyon/overview.html b/protocol/canyon/overview.html index 6676f930a..60f52a8c2 100644 --- a/protocol/canyon/overview.html +++ b/protocol/canyon/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/configurability.html b/protocol/configurability.html index 79b184b12..8cf628d3c 100644 --- a/protocol/configurability.html +++ b/protocol/configurability.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/delta/overview.html b/protocol/delta/overview.html index a3601d0d5..359a3d161 100644 --- a/protocol/delta/overview.html +++ b/protocol/delta/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/delta/span-batches.html b/protocol/delta/span-batches.html index 3232dddcf..b9de7318b 100644 --- a/protocol/delta/span-batches.html +++ b/protocol/delta/span-batches.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/deposits.html b/protocol/deposits.html index 2e8b7b28a..9edf1b72d 100644 --- a/protocol/deposits.html +++ b/protocol/deposits.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/derivation.html b/protocol/derivation.html index f67e22c5e..b84e7f620 100644 --- a/protocol/derivation.html +++ b/protocol/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/derivation.html b/protocol/ecotone/derivation.html index 69f48b18d..48edf5eae 100644 --- a/protocol/ecotone/derivation.html +++ b/protocol/ecotone/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/l1-attributes.html b/protocol/ecotone/l1-attributes.html index 94c9a9abb..fdba52917 100644 --- a/protocol/ecotone/l1-attributes.html +++ b/protocol/ecotone/l1-attributes.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/ecotone/overview.html b/protocol/ecotone/overview.html index ffb372c15..d95d00c2b 100644 --- a/protocol/ecotone/overview.html +++ b/protocol/ecotone/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/exec-engine.html b/protocol/exec-engine.html index a994871cc..115393699 100644 --- a/protocol/exec-engine.html +++ b/protocol/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/derivation.html b/protocol/fjord/derivation.html index 344bdbaf3..0a1ae0b01 100644 --- a/protocol/fjord/derivation.html +++ b/protocol/fjord/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/exec-engine.html b/protocol/fjord/exec-engine.html index 01d2281fd..69cb1bc77 100644 --- a/protocol/fjord/exec-engine.html +++ b/protocol/fjord/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/overview.html b/protocol/fjord/overview.html index 783db2fbb..30f1c440c 100644 --- a/protocol/fjord/overview.html +++ b/protocol/fjord/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/fjord/predeploys.html b/protocol/fjord/predeploys.html index bae67eae6..d46e6398f 100644 --- a/protocol/fjord/predeploys.html +++ b/protocol/fjord/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/derivation.html b/protocol/granite/derivation.html index e9d88dbae..e19cba517 100644 --- a/protocol/granite/derivation.html +++ b/protocol/granite/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/exec-engine.html b/protocol/granite/exec-engine.html index 8c0f1e46d..684d3fb06 100644 --- a/protocol/granite/exec-engine.html +++ b/protocol/granite/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/granite/overview.html b/protocol/granite/overview.html index 7b5492827..bb2905a4a 100644 --- a/protocol/granite/overview.html +++ b/protocol/granite/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/guaranteed-gas-market.html b/protocol/guaranteed-gas-market.html index c42c12354..863931f80 100644 --- a/protocol/guaranteed-gas-market.html +++ b/protocol/guaranteed-gas-market.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/holocene/derivation.html b/protocol/holocene/derivation.html index f1eea3faf..c38652a86 100644 --- a/protocol/holocene/derivation.html +++ b/protocol/holocene/derivation.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/holocene/exec-engine.html b/protocol/holocene/exec-engine.html index d44a82f56..4253e4082 100644 --- a/protocol/holocene/exec-engine.html +++ b/protocol/holocene/exec-engine.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -194,81 +194,36 @@ L2 Ex Table of Contents +Overview Timestamp Activation -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters -Header Validity Rules -Header Withdrawals Root - -Rationale -Forwards Compatibility Considerations -Client Implementation Considerations - - - - Extended PayloadAttributesV3 eip1559Params encoding -Execution -Rationale +Execution +Rationale eip1559Params in Header -Header Validity Rules +Header Validity Rules Encoding -Rationale +Rationale + + +Overview +The EIP-1559 parameters are encoded in the block header's nonce field and can be +configured dynamically through the SystemConfig. Timestamp Activation Holocene, like other network upgrades, is activated at a timestamp. Changes to the L2 Block execution rules are applied when the L2 Timestamp >= activation time. -L2ToL1MessagePasser Storage Root in Header -After Holocene's activation, the L2 block header's withdrawalsRoot field will consist of the 32-byte -L2ToL1MessagePasser account storage root after the block has been executed, and after the -insertions and deletions have been applied to the trie. In other words, the storage root should be the same root -that is returned by eth_getProof at the given block number. -Header Validity Rules -Prior to holocene activation, the L2 block header's withdrawalsRoot field must be: - -nil if Canyon has not been activated. -keccak256(rlp(empty_string_code)) if Canyon has been activated. - -After Holocene activation, an L2 block header's withdrawalsRoot field is valid iff: - -It is exactly 32 bytes in length. -The L2ToL1MessagePasser account storage root, as committed to in the storageRoot within the block -header, is equal to the header's withdrawalsRoot field. - -Header Withdrawals Root -Byte offsetDescription -[0, 32)L2ToL1MessagePasser account storage root - - -Rationale -Currently, to generate L2 output roots for historical blocks, an archival node is required. This directly -places a burden on users of the system in a post-fault-proofs world, where: - -A proposer must have an archive node to propose an output root at the safe head. -A user that is proving their withdrawal must have an archive node to verify that the output root they are proving -their withdrawal against is indeed valid and included within the safe chain. - -Placing the L2ToL1MessagePasser account storage root in the withdrawalsRoot field alleviates this burden -for users and protocol participants alike, allowing them to propose and verify other proposals with lower operating costs. -Forwards Compatibility Considerations -As it stands, the withdrawalsRoot field is unused within the OP Stack's header consensus format, and will never be -used for other reasons that are currently planned. Setting this value to the account storage root of the withdrawal -directly fits with the OP Stack, and makes use of the existing field in the L1 header consensus format. -Client Implementation Considerations -Varous EL clients store historical state of accounts differently. If, as a contrived case, an OP Stack chain did not have -an outbound withdrawal for a long period of time, the node may not have access to the account storage root of the -L2ToL1MessagePasser. In this case, the client would be unable to keep consensus. However, most modern -clients are able to at the very least reconstruct the account storage root at a given block on the fly if it does not -directly store this information. -Extended PayloadAttributesV3 +Dynamic EIP-1559 Parameters +Extended PayloadAttributesV3 The PayloadAttributesV3 type is extended to: PayloadAttributesV3: { @@ -283,7 +238,7 @@ eip1559Params encoding +eip1559Params encoding NameTypeByte Offset denominatoru32 (big-endian)[0, 4) elasticityu32 (big-endian)[4, 8) @@ -303,19 +258,19 @@ Execution -Rationale +Rationale This type is made available in the payload attributes to allow the block builder to dynamically control the EIP-1559 parameters of the chain. As described in the derivation - AttributesBuilder section, the derivation pipeline must populate this field from the SystemConfig during payload building, similar to how it must reference the SystemConfig for the gasLimit field. -eip1559Params in Header +eip1559Params in Header Upon Holocene activation, the L2 block header's nonce field will consist of the 8-byte eip1559Params value. -Header Validity Rules +Header Validity Rules Prior to Holocene activation, the L2 block header's nonce field is valid iff it is equal to u64(0). After Holocene activation, The L2 block header's nonce field is valid iff it is non-zero. -Encoding +Encoding The encoding of the eip1559Params value is described in eip1559Params encoding. -Rationale +Rationale By chosing to put the eip1559Params in the PayloadAttributes rather than in the L1 block info transaction, the EIP-1559 parameters for the chain are not available within history. This would place a burden on performing historical execution, as L1 would have to be consulted for fetching the values from the SystemConfig contract. diff --git a/protocol/holocene/overview.html b/protocol/holocene/overview.html index 0ce159035..1714698a1 100644 --- a/protocol/holocene/overview.html +++ b/protocol/holocene/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -199,10 +199,9 @@ Smart Contracts -This document is not finalized and should be considered experimental. Execution Layer -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters Consensus Layer @@ -210,8 +209,7 @@ Consensus Lay Smart Contracts -Predeploys -Configurability +System Config diff --git a/protocol/holocene/predeploys.html b/protocol/holocene/predeploys.html index 3c4f9c31d..3c6067ec3 100644 --- a/protocol/holocene/predeploys.html +++ b/protocol/holocene/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -189,209 +189,7 @@ OP Stack Specification -Overview - - -Table of Contents - -Constants -Predeploys - -L1Block - -Storage -Interface - -setHolocene -setConfig -baseFeeVaultConfig -sequencerFeeVaultConfig -l1FeeVaultConfig -l1CrossDomainMessenger -l1StandardBridge -l1ERC721Bridge -remoteChainId - - - - -FeeVault - -Interface - -config - - - - -L2CrossDomainMessenger - -Interface - - -L2ERC721Bridge - -Interface - - -L2StandardBridge - -Interface - - -OptimismMintableERC721Factory - - -Security Considerations - -GovernanceToken - - - - -This upgrade enables a deterministic L2 genesis state by moving all network -specific configuration out of the initial L2 genesis state. All network specific -configuration is sourced from deposit transactions during the initialization -of the SystemConfig. -Constants -NameValueDefinition -ConfigTypeuint8An enum representing the type of config being set -WithdrawalNetworkuint8(0) or uint8(1)0 means withdraw to L1, 1 means withdraw to L2 -RECIPIENTaddressThe account that will receive funds sent out of the FeeVault -MIN_WITHDRAWAL_AMOUNTuint256The minimum amount of native asset held in the FeeVault before withdrawal is authorized -Fee Vault Configbytes32bytes32((WithdrawalNetwork << 248) || uint256(uint88(MIN_WITHDRAWAL_AMOUNT)) || uint256(uint160(RECIPIENT))) -BASE_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.basefeevaultconfig")) - 1)The Fee Vault Config for the BaseFeeVault -L1_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.l1feevaultconfig")) - 1)The Fee Vault Config for the L1FeeVault -SEQUENCER_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.sequencerfeevaultconfig")) - 1)The Fee Vault Config for the SequencerFeeVault -L1_CROSS_DOMAIN_MESSENGER_ADDRESSbytes32(uint256(keccak256("opstack.l1crossdomainmessengeraddress")) - 1)abi.encode(address(L1CrossDomainMessengerProxy)) -L1_ERC_721_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1erc721bridgeaddress")) - 1)abi.encode(address(L1ERC721BridgeProxy)) -L1_STANDARD_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1standardbridgeaddress")) - 1)abi.encode(address(L1StandardBridgeProxy)) -REMOTE_CHAIN_IDbytes32(uint256(keccak256("opstack.remotechainid")) - 1)Chain ID of the remote chain - - -Predeploys -All network specific configuration is moved to a single contract, the L1Block predeploy. -All predeploys make calls to the L1Block contract to fetch network specific configuration -rather than reading it from local state. -graph LR - subgraph L1 - SystemConfig -- "setConfig(uint8,bytes)" --> OptimismPortal - end - subgraph L2 - L1Block - BaseFeeVault -- "baseFeeVaultConfig()(address,uint256,uint8)" --> L1Block - SequencerFeeVault -- "sequencerFeeVaultConfig()(address,uint256,uint8)" --> L1Block - L1FeeVault -- "l1FeeVaultConfig()(address,uint256,uint8)" --> L1Block - L2CrossDomainMessenger -- "l1CrossDomainMessenger()(address)" --> L1Block - L2StandardBridge -- "l1StandardBridge()(address)" --> L1Block - L2ERC721Bridge -- "l1ERC721Bridge()(address)" --> L1Block - OptimismMintableERC721Factory -- "remoteChainId()(uint256)" --> L1Block - end - OptimismPortal -- "setConfig(uint8,bytes)" --> L1Block - -L1Block -Storage -The following storage slots are defined: - -BASE_FEE_VAULT_CONFIG -L1_FEE_VAULT_CONFIG -SEQUENCER_FEE_VAULT_CONFIG -L1_CROSS_DOMAIN_MESSENGER_ADDRESS -L1_ERC_721_BRIDGE_ADDRESS -L1_STANDARD_BRIDGE_ADDRESS -REMOTE_CHAIN_ID - -Each slot MUST have a defined ConfigType that authorizes the setting of the storage slot -via a deposit transaction from the DEPOSITOR_ACCOUNT. -Interface -setHolocene -This function is meant to be called once on the activation block of the holocene network upgrade. -It MUST only be callable by the DEPOSITOR_ACCOUNT once. When it is called, it MUST call -call each getter for the network specific config and set the returndata into storage. -setConfig -This function MUST only be callable by the DEPOSITOR_ACCOUNT. It modifies the storage directly -of the L1Block contract. It MUST handle all defined ConfigTypes. To ensure a simple ABI, the -bytes value MUST be abi decoded based on the ConfigType. -function setConfig(ConfigType,bytes) - -Note that ConfigType is an enum which is an alias for a uint8. -baseFeeVaultConfig -This function MUST be called by the BaseFeeVault to fetch network specific configuration. -function baseFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -sequencerFeeVaultConfig -This function MUST be called by the SequencerFeeVault to fetch network specific configuration. -function sequencerFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1FeeVaultConfig -This function MUST be called by the L1FeeVault to fetch network specific configuration. -function l1FeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1CrossDomainMessenger -This function MUST be called by the L2CrossDomainMessenger to fetch the address of the L1CrossDomainMessenger. -function l1CrossDomainMessenger()(address) - -l1StandardBridge -This function MUST be called by the L2StandardBridge to fetch the address of the L2CrossDomainMessenger. -function l1StandardBridge()(address) - -l1ERC721Bridge -This function MUST be called by the L2ERC721Bridge to fetch the address of the L1ERC721Bridge. -function l1ERC721Bridge()(address) - -remoteChainId -This function MUST be called by the OptimismMintableERC721Factory to fetch the chain id of the remote chain. -For an L2, this is the L1 chain id. -function remoteChainId()(uint256) - -FeeVault -The following changes apply to each of the BaseFeeVault, the L1FeeVault and the SequencerFeeVault. -Interface -The following functions are updated to read from the L1Block contract: - -recipient()(address) -withdrawalNetwork()(WithdrawalNetwork) -minWithdrawalAmount()(uint256) -withdraw() - -NameCall -BaseFeeVaultL1Block.baseFeeVaultConfig() -SequencerFeeVaultL1Block.sequencerFeeVaultConfig() -L1FeeVaultL1Block.l1FeeVaultConfig() - - -config -A new function is added to fetch the full Fee Vault Config. -function config()(address,uint256,WithdrawalNetwork) - -L2CrossDomainMessenger -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1CrossDomainMessenger(): - -otherMessenger()(address) -OTHER_MESSENGER()(address) - -L2ERC721Bridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1ERC721Bridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -L2StandardBridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1StandardBridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -OptimismMintableERC721Factory -The chain id is no longer read from storage but instead is read from the L1Block contract by calling -L1Block.remoteChainId() -Security Considerations -GovernanceToken -The predeploy defined by GovernanceToken should be an empty account until it is defined by -a future hardfork. +Predeploys @@ -401,7 +199,7 @@ GovernanceTok - + @@ -415,7 +213,7 @@ GovernanceTok - + diff --git a/protocol/holocene/configurability.html b/protocol/holocene/system-config.html similarity index 72% rename from protocol/holocene/configurability.html rename to protocol/holocene/system-config.html index 985283b56..0df792e3e 100644 --- a/protocol/holocene/configurability.html +++ b/protocol/holocene/system-config.html @@ -3,7 +3,7 @@ - Configurability - OP Stack Specification + System Config - OP Stack Specification @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -159,7 +159,7 @@ OP Stack Specification - + @@ -189,18 +189,12 @@ OP Stack Specification -Configurability +System Config Table of Contents -Overview -Constants - -ConfigType - - -SystemConfig +Overview ConfigUpdate Initialization @@ -214,22 +208,6 @@ Configurabili eip1559Denominator -Fee Vault Config - -setBaseFeeVaultConfig -setL1FeeVaultConfig -setSequencerFeeVaultConfig - - - - - - -OptimismPortal - -Interface - -setConfig @@ -237,23 +215,7 @@ Configurabili Overview -The SystemConfig and OptimismPortal are updated with a new flow for chain -configurability. -Constants -ConfigType -The ConfigType enum represents configuration that can be modified. -NameValueDescription -SET_GAS_PAYING_TOKENuint8(0)Modifies the gas paying token for the chain -SET_BASE_FEE_VAULT_CONFIGuint8(1)Sets the Fee Vault Config for the BaseFeeVault -SET_L1_FEE_VAULT_CONFIGuint8(2)Sets the Fee Vault Config for the L1FeeVault -SET_SEQUENCER_FEE_VAULT_CONFIGuint8(3)Sets the Fee Vault Config for the SequencerFeeVault -SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESSuint8(4)Sets the L1CrossDomainMessenger address -SET_L1_ERC_721_BRIDGE_ADDRESSuint8(5)Sets the L1ERC721Bridge address -SET_L1_STANDARD_BRIDGE_ADDRESSuint8(6)Sets the L1StandardBridge address -SET_REMOTE_CHAIN_IDuint8(7)Sets the chain id of the base chain - - -SystemConfig +The SystemConfig is updated to allow for dynamic EIP-1559 parameters. ConfigUpdate The following ConfigUpdate event is defined where the CONFIG_VERSION is uint256(0): NameValueDefinitionUsage @@ -272,16 +234,7 @@ Initialization< emit ConfigUpdate.GAS_LIMIT emit ConfigUpdate.UNSAFE_BLOCK_SIGNER emit ConfigUpdate.EIP_1559_PARAMS -setConfig(SET_GAS_PAYING_TOKEN) -setConfig(SET_BASE_FEE_VAULT_CONFIG) -setConfig(SET_L1_FEE_VAULT_CONFIG) -setConfig(SET_SEQUENCER_FEE_VAULT_CONFIG) -setConfig(SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESS) -setConfig(SET_L1_ERC_721_BRIDGE_ADDRESS) -setConfig(SET_L1_STANDARD_BRIDGE_ADDRESS) -setConfig(SET_REMOTE_CHAIN_ID) -These actions MAY only be triggered if there is a diff to the value. Modifying EIP-1559 Parameters A new SystemConfig UpdateType is introduced that enables the modification of EIP-1559 parameters. This allows for the chain @@ -302,39 +255,6 @@ e This function returns the currently configured EIP-1559 denominator. function eip1559Denominator()(uint64) -Fee Vault Config -For each FeeVault, there is a setter for its config. The arguments to the setter include -the RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork. -Each of these functions should be public and only callable by the chain governor. -Each function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType. -setBaseFeeVaultConfig -function setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork) - -setL1FeeVaultConfig -function setL1FeeVaultConfig(address,uint256,WithdrawalNetwork) - -setSequencerFeeVaultConfig -function setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork) - -OptimismPortal -The OptimismPortal is updated to emit a special system TransactionDeposited event. -Interface -setConfig -The setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig -is the single source of truth for chain operator ownership. -function setConfig(ConfigType,bytes) - -This function emits a TransactionDeposited event. -event TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData); - -The following fields are included: - -from is the DEPOSITOR_ACCOUNT -to is Predeploys.L1Block -version is uint256(0) -opaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit -is 200_000, isCreation is false and the data is abi.encodeCall(L1Block.setConfig, (_type, _value)) - diff --git a/protocol/messengers.html b/protocol/messengers.html index 5719b0eac..b0c6745a4 100644 --- a/protocol/messengers.html +++ b/protocol/messengers.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/overview.html b/protocol/overview.html index 19a171b6b..8d974911d 100644 --- a/protocol/overview.html +++ b/protocol/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/precompiles.html b/protocol/precompiles.html index 2636bcded..591225781 100644 --- a/protocol/precompiles.html +++ b/protocol/precompiles.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/predeploys.html b/protocol/predeploys.html index f69344d63..18f80ecc9 100644 --- a/protocol/predeploys.html +++ b/protocol/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/preinstalls.html b/protocol/preinstalls.html index a3e678702..de25cd1f4 100644 --- a/protocol/preinstalls.html +++ b/protocol/preinstalls.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/proposals.html b/protocol/proposals.html index 4356aed7b..c7e27aba0 100644 --- a/protocol/proposals.html +++ b/protocol/proposals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/regolith/overview.html b/protocol/regolith/overview.html index 25fb28a59..735c8d392 100644 --- a/protocol/regolith/overview.html +++ b/protocol/regolith/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node-p2p.html b/protocol/rollup-node-p2p.html index 6b7b877ad..f733fce32 100644 --- a/protocol/rollup-node-p2p.html +++ b/protocol/rollup-node-p2p.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node.html b/protocol/rollup-node.html index 7b2194855..74e7465df 100644 --- a/protocol/rollup-node.html +++ b/protocol/rollup-node.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/safe-extensions.html b/protocol/safe-extensions.html index c13615619..4601198ba 100644 --- a/protocol/safe-extensions.html +++ b/protocol/safe-extensions.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/stage-1.html b/protocol/stage-1.html index d28f06461..2659aa26c 100644 --- a/protocol/stage-1.html +++ b/protocol/stage-1.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-configuration.html b/protocol/superchain-configuration.html index ee7a3f560..6796bb40e 100644 --- a/protocol/superchain-configuration.html +++ b/protocol/superchain-configuration.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-upgrades.html b/protocol/superchain-upgrades.html index e9ac90b28..aad45a9b2 100644 --- a/protocol/superchain-upgrades.html +++ b/protocol/superchain-upgrades.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/system-config.html b/protocol/system-config.html index afbdefd92..d5fe843f1 100644 --- a/protocol/system-config.html +++ b/protocol/system-config.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/withdrawals.html b/protocol/withdrawals.html index e390c5450..8596661a9 100644 --- a/protocol/withdrawals.html +++ b/protocol/withdrawals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/root.html b/root.html index 20d712d67..bd978d50b 100644 --- a/root.html +++ b/root.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/searchindex.js b/searchindex.js index 371b06267..623744500 100644 --- a/searchindex.js +++ b/searchindex.js @@ -1 +1 @@ -Object.assign(window.search, {"doc_urls":["root.html#op-stack-specification","root.html#about-optimism","root.html#about-the-op-stack","root.html#site-navigation","background.html#background","background.html#overview","background.html#foundations","background.html#ethereum-scalability","background.html#optimistic-rollups","background.html#evm-equivalence","background.html#protocol-guarantees","background.html#liveness","background.html#validity","background.html#availability","background.html#network-participants","background.html#users","background.html#sequencers","background.html#verifiers","background.html#key-interaction-diagrams","background.html#depositing-and-sending-transactions","background.html#withdrawing","background.html#next-steps","protocol/overview.html#optimism-overview","protocol/overview.html#architecture-design-goals","protocol/overview.html#architecture-overview","protocol/overview.html#core-l1-smart-contracts","protocol/overview.html#core-l2-smart-contracts","protocol/overview.html#smart-contract-proxies","protocol/overview.html#l2-node-components","protocol/overview.html#transactionblock-propagation","protocol/overview.html#key-interactions-in-depth","protocol/overview.html#deposits","protocol/overview.html#block-derivation","protocol/overview.html#engine-api","protocol/bridges.html#standard-bridges","protocol/bridges.html#overview","protocol/bridges.html#token-depositing","protocol/bridges.html#upgradability","protocol/messengers.html#cross-domain-messengers","protocol/messengers.html#overview","protocol/messengers.html#message-passing","protocol/messengers.html#upgradability","protocol/messengers.html#message-versioning","protocol/messengers.html#message-version-0","protocol/messengers.html#message-version-1","protocol/messengers.html#backwards-compatibility-notes","protocol/deposits.html#deposits","protocol/deposits.html#overview","protocol/deposits.html#the-deposited-transaction-type","protocol/deposits.html#source-hash-computation","protocol/deposits.html#kinds-of-deposited-transactions","protocol/deposits.html#validation-and-authorization-of-deposited-transactions","protocol/deposits.html#execution","protocol/deposits.html#deposit-receipt","protocol/deposits.html#l1-attributes-deposited-transaction","protocol/deposits.html#l1-attributes-deposited-transaction-calldata","protocol/deposits.html#special-accounts-on-l2","protocol/deposits.html#l1-attributes-depositor-account","protocol/deposits.html#l1-attributes-predeployed-contract","protocol/deposits.html#user-deposited-transactions","protocol/deposits.html#deposit-contract","protocol/withdrawals.html#withdrawals","protocol/withdrawals.html#overview","protocol/withdrawals.html#withdrawal-flow","protocol/withdrawals.html#on-l2","protocol/withdrawals.html#on-l1","protocol/withdrawals.html#the-l2tol1messagepasser-contract","protocol/withdrawals.html#addresses-are-not-aliased-on-withdrawals","protocol/withdrawals.html#the-optimism-portal-contract","protocol/withdrawals.html#withdrawal-verification-and-finalization","protocol/withdrawals.html#security-considerations","protocol/withdrawals.html#key-properties-of-withdrawal-verification","protocol/withdrawals.html#handling-successfully-verified-messages-that-fail-when-relayed","protocol/withdrawals.html#optimismportal-can-send-arbitrary-messages-on-l1","protocol/guaranteed-gas-market.html#guaranteed-gas-fee-market","protocol/guaranteed-gas-market.html#overview","protocol/guaranteed-gas-market.html#gas-stipend","protocol/guaranteed-gas-market.html#default-values","protocol/guaranteed-gas-market.html#limiting-guaranteed-gas","protocol/guaranteed-gas-market.html#rationale-for-burning-l1-gas","protocol/guaranteed-gas-market.html#on-preventing-griefing-attacks","protocol/proposals.html#l2-output-root-proposals-specification","protocol/proposals.html#overview","protocol/proposals.html#proposing-l2-output-commitments","protocol/proposals.html#l2outputoracle-v100","protocol/proposals.html#l2-output-commitment-construction","protocol/proposals.html#l2-output-oracle-smart-contract","protocol/proposals.html#configuration","protocol/proposals.html#security-considerations","protocol/proposals.html#l1-reorgs","protocol/exec-engine.html#l2-execution-engine","protocol/exec-engine.html#1559-parameters","protocol/exec-engine.html#deposited-transaction-processing","protocol/exec-engine.html#deposited-transaction-boundaries","protocol/exec-engine.html#fees","protocol/exec-engine.html#fee-vaults","protocol/exec-engine.html#priority-fees-sequencer-fee-vault","protocol/exec-engine.html#base-fees-base-fee-vault","protocol/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/exec-engine.html#engine-api","protocol/exec-engine.html#engine_forkchoiceupdatedv2","protocol/exec-engine.html#engine_forkchoiceupdatedv3","protocol/exec-engine.html#engine_newpayloadv2","protocol/exec-engine.html#engine_newpayloadv3","protocol/exec-engine.html#engine_getpayloadv2","protocol/exec-engine.html#engine_getpayloadv3","protocol/exec-engine.html#engine_signalsuperchainv1","protocol/exec-engine.html#networking","protocol/exec-engine.html#sync","protocol/exec-engine.html#happy-path-sync","protocol/exec-engine.html#worst-case-sync","protocol/exec-engine.html#ecotone-disable-blob-transactions","protocol/exec-engine.html#ecotone-beacon-block-root","protocol/exec-engine.html#p2p-modifications","protocol/rollup-node.html#rollup-node-specification","protocol/rollup-node.html#overview","protocol/rollup-node.html#driver","protocol/rollup-node.html#derivation","protocol/rollup-node.html#l2-output-rpc-method","protocol/rollup-node.html#structures","protocol/rollup-node.html#output-method-api","protocol/rollup-node.html#protocol-version-tracking","protocol/rollup-node-p2p.html#rollup-node-p2p-interface","protocol/rollup-node-p2p.html#overview","protocol/rollup-node-p2p.html#p2p-configuration","protocol/rollup-node-p2p.html#identification","protocol/rollup-node-p2p.html#discv5","protocol/rollup-node-p2p.html#libp2p","protocol/rollup-node-p2p.html#gossip-topics","protocol/rollup-node-p2p.html#blocksv1","protocol/rollup-node-p2p.html#blocksv2","protocol/rollup-node-p2p.html#blocksv3","protocol/rollup-node-p2p.html#block-encoding","protocol/rollup-node-p2p.html#block-signatures","protocol/rollup-node-p2p.html#block-validation","protocol/rollup-node-p2p.html#req-resp","protocol/rollup-node-p2p.html#payload_by_number","protocol/derivation.html#l2-chain-derivation-specification","protocol/derivation.html#overview","protocol/derivation.html#eager-block-derivation","protocol/derivation.html#protocol-parameters","protocol/derivation.html#batch-submission","protocol/derivation.html#sequencing--batch-submission-overview","protocol/derivation.html#batch-submission-wire-format","protocol/derivation.html#batcher-transaction-format","protocol/derivation.html#frame-format","protocol/derivation.html#channel-format","protocol/derivation.html#batch-format","protocol/derivation.html#architecture","protocol/derivation.html#l2-chain-derivation-pipeline","protocol/derivation.html#l1-traversal","protocol/derivation.html#l1-retrieval","protocol/derivation.html#frame-queue","protocol/derivation.html#channel-bank","protocol/derivation.html#channel-reader-batch-decoding","protocol/derivation.html#batch-queue","protocol/derivation.html#payload-attributes-derivation","protocol/derivation.html#engine-queue","protocol/derivation.html#resetting-the-pipeline","protocol/derivation.html#deriving-payload-attributes","protocol/derivation.html#deriving-the-transaction-list","protocol/derivation.html#network-upgrade-automation-transactions","protocol/derivation.html#building-individual-payload-attributes","protocol/batcher.html#batch-submitter","protocol/batcher.html#overview","fault-proof/index.html#fault-proof","fault-proof/index.html#overview","fault-proof/index.html#pre-image-oracle","fault-proof/index.html#pre-image-key-types","fault-proof/index.html#bootstrapping","fault-proof/index.html#hinting","fault-proof/index.html#pre-image-communication","fault-proof/index.html#fault-proof-program","fault-proof/index.html#prologue","fault-proof/index.html#main-content","fault-proof/index.html#epilogue","fault-proof/index.html#pre-image-hinting-routes","fault-proof/index.html#precompile-accelerators","fault-proof/index.html#fault-proof-vm","fault-proof/index.html#fault-proof-interactive-dispute-game","fault-proof/cannon-fault-proof-vm.html#cannon-fault-proof-virtual-machine","fault-proof/cannon-fault-proof-vm.html#overview","fault-proof/cannon-fault-proof-vm.html#state","fault-proof/cannon-fault-proof-vm.html#state-hash","fault-proof/cannon-fault-proof-vm.html#memory","fault-proof/cannon-fault-proof-vm.html#heap","fault-proof/cannon-fault-proof-vm.html#delay-slots","fault-proof/cannon-fault-proof-vm.html#syscalls","fault-proof/cannon-fault-proof-vm.html#io","fault-proof/cannon-fault-proof-vm.html#standard-streams","fault-proof/cannon-fault-proof-vm.html#hint-communication","fault-proof/cannon-fault-proof-vm.html#pre-image-communication","fault-proof/cannon-fault-proof-vm.html#exceptions","fault-proof/cannon-fault-proof-vm.html#security-model","fault-proof/cannon-fault-proof-vm.html#compiler-correctness","fault-proof/cannon-fault-proof-vm.html#compiler-assumptions","fault-proof/stage-one/index.html#stage-one-decentralization","fault-proof/stage-one/dispute-game-interface.html#dispute-game-interface","fault-proof/stage-one/dispute-game-interface.html#overview","fault-proof/stage-one/dispute-game-interface.html#types","fault-proof/stage-one/dispute-game-interface.html#disputegamefactory-interface","fault-proof/stage-one/dispute-game-interface.html#disputegame-interface","fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game","fault-proof/stage-one/fault-dispute-game.html#overview","fault-proof/stage-one/fault-dispute-game.html#definitions","fault-proof/stage-one/fault-dispute-game.html#virtual-machine-vm","fault-proof/stage-one/fault-dispute-game.html#preimageoracle","fault-proof/stage-one/fault-dispute-game.html#execution-trace","fault-proof/stage-one/fault-dispute-game.html#claims","fault-proof/stage-one/fault-dispute-game.html#anchor-state","fault-proof/stage-one/fault-dispute-game.html#anchor-state-registry","fault-proof/stage-one/fault-dispute-game.html#dag","fault-proof/stage-one/fault-dispute-game.html#subgame","fault-proof/stage-one/fault-dispute-game.html#game-tree","fault-proof/stage-one/fault-dispute-game.html#position","fault-proof/stage-one/fault-dispute-game.html#max_clock_duration","fault-proof/stage-one/fault-dispute-game.html#clock_extension","fault-proof/stage-one/fault-dispute-game.html#freeloader-claims","fault-proof/stage-one/fault-dispute-game.html#core-game-mechanics","fault-proof/stage-one/fault-dispute-game.html#actors","fault-proof/stage-one/fault-dispute-game.html#moves","fault-proof/stage-one/fault-dispute-game.html#l2-block-number-challenge","fault-proof/stage-one/fault-dispute-game.html#step","fault-proof/stage-one/fault-dispute-game.html#step-types","fault-proof/stage-one/fault-dispute-game.html#preimageoracle-interaction","fault-proof/stage-one/fault-dispute-game.html#team-dynamics","fault-proof/stage-one/fault-dispute-game.html#game-clock","fault-proof/stage-one/fault-dispute-game.html#resolution","fault-proof/stage-one/fault-dispute-game.html#finalization","fault-proof/stage-one/honest-challenger-fdg.html#honest-challenger-fault-dispute-game","fault-proof/stage-one/honest-challenger-fdg.html#overview","fault-proof/stage-one/honest-challenger-fdg.html#invariants","fault-proof/stage-one/honest-challenger-fdg.html#fault-dispute-game-responses","fault-proof/stage-one/honest-challenger-fdg.html#moves","fault-proof/stage-one/honest-challenger-fdg.html#steps","fault-proof/stage-one/honest-challenger-fdg.html#timeliness","fault-proof/stage-one/honest-challenger-fdg.html#resolution","fault-proof/stage-one/bond-incentives.html#bond-incentives","fault-proof/stage-one/bond-incentives.html#overview","fault-proof/stage-one/bond-incentives.html#moves","fault-proof/stage-one/bond-incentives.html#subgame-resolution","fault-proof/stage-one/bond-incentives.html#leftmost-claim-incentives","fault-proof/stage-one/bond-incentives.html#fault-proof-mainnet-incentives","fault-proof/stage-one/bond-incentives.html#authenticated-roles","fault-proof/stage-one/bond-incentives.html#base-fee-assumption","fault-proof/stage-one/bond-incentives.html#bond-scaling","fault-proof/stage-one/bond-incentives.html#required-bond-formula","fault-proof/stage-one/bond-incentives.html#other-incentives","fault-proof/stage-one/bond-incentives.html#delayedweth","fault-proof/stage-one/bridge-integration.html#bridge-integration","fault-proof/stage-one/bridge-integration.html#overview","fault-proof/stage-one/bridge-integration.html#legacy-semantics","fault-proof/stage-one/bridge-integration.html#fpac-optimismportal-mods-specification","fault-proof/stage-one/bridge-integration.html#roles---optimismportal","fault-proof/stage-one/bridge-integration.html#new-deployconfig-variables","fault-proof/stage-one/bridge-integration.html#data-structures","fault-proof/stage-one/bridge-integration.html#state-layout","fault-proof/stage-one/bridge-integration.html#provewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#finalizewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#air-gap","fault-proof/stage-one/bridge-integration.html#proxy-upgrade","fault-proof/stage-one/bridge-integration.html#permissioned-faultdisputegame","fault-proof/stage-one/bridge-integration.html#roles---permissioneddisputegame","fault-proof/stage-one/bridge-integration.html#modifications","protocol/precompiles.html#precompiles","protocol/precompiles.html#overview","protocol/precompiles.html#p256verify","protocol/predeploys.html#predeploys","protocol/predeploys.html#overview","protocol/predeploys.html#legacymessagepasser","protocol/predeploys.html#l2tol1messagepasser","protocol/predeploys.html#deployerwhitelist","protocol/predeploys.html#legacyerc20eth","protocol/predeploys.html#weth9","protocol/predeploys.html#l2crossdomainmessenger","protocol/predeploys.html#l2standardbridge","protocol/predeploys.html#l1blocknumber","protocol/predeploys.html#gaspriceoracle","protocol/predeploys.html#l1block","protocol/predeploys.html#proxyadmin","protocol/predeploys.html#sequencerfeevault","protocol/predeploys.html#optimismmintableerc20factory","protocol/predeploys.html#optimismmintableerc721factory","protocol/predeploys.html#basefeevault","protocol/predeploys.html#l1feevault","protocol/predeploys.html#schemaregistry","protocol/predeploys.html#eas","protocol/predeploys.html#beacon-block-root","protocol/preinstalls.html#preinstalls","protocol/preinstalls.html#overview","protocol/preinstalls.html#safe","protocol/preinstalls.html#safel2","protocol/preinstalls.html#multisend","protocol/preinstalls.html#multisendcallonly","protocol/preinstalls.html#safesingletonfactory","protocol/preinstalls.html#multicall3","protocol/preinstalls.html#create2deployer","protocol/preinstalls.html#createx","protocol/preinstalls.html#arachnids-deterministic-deployment-proxy","protocol/preinstalls.html#permit2","protocol/preinstalls.html#erc-4337-v060-entrypoint","protocol/preinstalls.html#erc-4337-v060-sendercreator","protocol/preinstalls.html#erc-4337-v070-entrypoint","protocol/preinstalls.html#erc-4337-v070-sendercreator","protocol/superchain-configuration.html#superchain-configuration","protocol/superchain-configuration.html#overview","protocol/superchain-configuration.html#configurable-values","protocol/superchain-configuration.html#configuration-data-flow","protocol/superchain-configuration.html#pausability","protocol/superchain-upgrades.html#superchain-upgrades","protocol/superchain-upgrades.html#overview","protocol/superchain-upgrades.html#protocol-version","protocol/superchain-upgrades.html#protocol-version-format","protocol/superchain-upgrades.html#protocol-version-exposure","protocol/superchain-upgrades.html#superchain-target","protocol/superchain-upgrades.html#superchain-version-signaling","protocol/superchain-upgrades.html#protocolversions-l1-contract","protocol/superchain-upgrades.html#activation-rules","protocol/superchain-upgrades.html#l2-block-number-based-activation-deprecated","protocol/superchain-upgrades.html#l2-block-timestamp-based-activation","protocol/superchain-upgrades.html#op-stack-protocol-versions","protocol/superchain-upgrades.html#post-bedrock-network-upgrades","protocol/superchain-upgrades.html#activation-timestamps","protocol/system-config.html#system-config","protocol/system-config.html#overview","protocol/system-config.html#system-config-contents-version-0","protocol/system-config.html#batcherhash-bytes32","protocol/system-config.html#scalars","protocol/system-config.html#gaslimit-uint64","protocol/system-config.html#unsafeblocksigner-address","protocol/system-config.html#writing-the-system-config","protocol/system-config.html#reading-the-system-config","protocol/configurability.html#op-stack-configurability","protocol/configurability.html#consensus-parameters","protocol/configurability.html#batch-inbox-address","protocol/configurability.html#batcher-hash","protocol/configurability.html#chain-id","protocol/configurability.html#proof-maturity-delay","protocol/configurability.html#dispute-game-finality","protocol/configurability.html#respected-game-type","protocol/configurability.html#fault-game-max-depth","protocol/configurability.html#fault-game-split-depth","protocol/configurability.html#max-game-clock-duration","protocol/configurability.html#game-clock-extension","protocol/configurability.html#bond-withdrawal-delay","protocol/configurability.html#minimum-large-preimage-proposal-size","protocol/configurability.html#large-preimage-proposal-challenge-period","protocol/configurability.html#fault-game-absolute-prestate","protocol/configurability.html#fault-game-genesis-block","protocol/configurability.html#fault-game-genesis-output-root","protocol/configurability.html#fee-scalar","protocol/configurability.html#gas-limit","protocol/configurability.html#genesis-state","protocol/configurability.html#l2-block-time","protocol/configurability.html#resource-config","protocol/configurability.html#sequencing-window-size","protocol/configurability.html#start-block","protocol/configurability.html#superchain-target","protocol/configurability.html#governance-token","protocol/configurability.html#resource-config-1","protocol/configurability.html#policy-parameters","protocol/configurability.html#data-availability-type","protocol/configurability.html#batch-submission-frequency","protocol/configurability.html#output-frequency","protocol/configurability.html#admin-roles","protocol/configurability.html#l1-proxy-admin","protocol/configurability.html#l1-proxyadmin-owner","protocol/configurability.html#l2-proxy-admin","protocol/configurability.html#l2-proxyadmin-owner","protocol/configurability.html#system-config-owner","protocol/configurability.html#service-roles","protocol/configurability.html#batch-submitter-address","protocol/configurability.html#challenger-address","protocol/configurability.html#guardian-address","protocol/configurability.html#proposer-address","protocol/configurability.html#sequencer-p2p--unsafe-head-signer","protocol/safe-extensions.html#safe-contract-extensions","protocol/safe-extensions.html#guardian-safe","protocol/safe-extensions.html#deputy-guardian-module","protocol/safe-extensions.html#deputy-guardian-module-security-properties","protocol/safe-extensions.html#security-council-liveness-checking-extensions","protocol/safe-extensions.html#the-liveness-guard","protocol/safe-extensions.html#the-liveness-module","protocol/safe-extensions.html#owner-removal-call-flow","protocol/safe-extensions.html#shutdown","protocol/safe-extensions.html#liveness-security-properties","protocol/safe-extensions.html#interdependency-between-the-liveness-guard-and-liveness-module","protocol/safe-extensions.html#operational-considerations","protocol/safe-extensions.html#manual-validation-of-new-owner-liveness","protocol/safe-extensions.html#deploying-the-liveness-checking-system","protocol/safe-extensions.html#modifying-the-liveness-checking-system","protocol/stage-1.html#stage-1-roles-and-requirements","protocol/stage-1.html#overview","protocol/stage-1.html#permissionless-fault-proofs","protocol/stage-1.html#roles-for-stage-1","protocol/stage-1.html#configuration-of-safes","protocol/stage-1.html#ownership-model-diagram","protocol/regolith/overview.html#regolith","protocol/regolith/overview.html#overview","protocol/canyon/overview.html#canyon","protocol/canyon/overview.html#execution-layer","protocol/canyon/overview.html#consensus-layer","protocol/delta/overview.html#delta","protocol/delta/overview.html#consensus-layer","protocol/delta/span-batches.html#span-batches","protocol/delta/span-batches.html#introduction","protocol/delta/span-batches.html#span-batch-format","protocol/delta/span-batches.html#span-batch-size-limits","protocol/delta/span-batches.html#future-batch-format-extension","protocol/delta/span-batches.html#span-batch-activation-rule","protocol/delta/span-batches.html#optimization-strategies","protocol/delta/span-batches.html#truncating-information-and-storing-only-necessary-data","protocol/delta/span-batches.html#tx_data_headers-removal-from-initial-specs","protocol/delta/span-batches.html#chain-id-removal-from-initial-specs","protocol/delta/span-batches.html#reorganization-of-constant-length-transaction-fields","protocol/delta/span-batches.html#rlp-encoding-for-only-variable-length-fields","protocol/delta/span-batches.html#store-y_parity-and-protected_bit-instead-of-v","protocol/delta/span-batches.html#adjust-txs-data-layout-for-better-compression","protocol/delta/span-batches.html#fee_recipients-encoding-scheme","protocol/delta/span-batches.html#how-derivation-works-with-span-batches","protocol/delta/span-batches.html#integration","protocol/delta/span-batches.html#channel-reader-batch-decoding","protocol/delta/span-batches.html#batch-queue","protocol/delta/span-batches.html#batcher","protocol/ecotone/overview.html#ecotone-network-upgrade","protocol/ecotone/overview.html#execution-layer","protocol/ecotone/overview.html#consensus-layer","protocol/ecotone/derivation.html#derivation","protocol/ecotone/derivation.html#ecotone-blob-retrieval","protocol/ecotone/derivation.html#blob-encoding","protocol/ecotone/l1-attributes.html#ecotone-l1-attributes","protocol/ecotone/l1-attributes.html#overview","protocol/ecotone/l1-attributes.html#l1-attributes-predeployed-contract","protocol/ecotone/l1-attributes.html#ecotone-l1block-upgrade","protocol/fjord/overview.html#fjord-network-upgrade","protocol/fjord/overview.html#execution-layer","protocol/fjord/overview.html#consensus-layer","protocol/fjord/exec-engine.html#l2-execution-engine","protocol/fjord/exec-engine.html#fees","protocol/fjord/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/fjord/exec-engine.html#l1-gas-usage-estimation","protocol/fjord/derivation.html#fjord-l2-chain-derivation-changes","protocol/fjord/derivation.html#protocol-parameter-changes","protocol/fjord/derivation.html#timestamp-activation","protocol/fjord/derivation.html#constant-maximum-sequencer-drift","protocol/fjord/derivation.html#rationale","protocol/fjord/derivation.html#security-considerations","protocol/fjord/derivation.html#increasing-max_rlp_bytes_per_channel-and-max_channel_bank_size","protocol/fjord/derivation.html#rationale-1","protocol/fjord/derivation.html#security-considerations-1","protocol/fjord/derivation.html#brotli-channel-compression","protocol/fjord/derivation.html#network-upgrade-automation-transactions","protocol/fjord/derivation.html#gaspriceoracle-deployment","protocol/fjord/derivation.html#gaspriceoracle-proxy-update","protocol/fjord/derivation.html#gaspriceoracle-enable-fjord","protocol/fjord/predeploys.html#predeploys","protocol/fjord/predeploys.html#gaspriceoracle","protocol/fjord/predeploys.html#l1-gas-usage-estimation","protocol/granite/overview.html#granite-network-upgrade","protocol/granite/overview.html#execution-layer","protocol/granite/overview.html#consensus-layer","protocol/granite/exec-engine.html#l2-execution-engine","protocol/granite/exec-engine.html#evm-changes","protocol/granite/exec-engine.html#bn256pairing-precompile-input-restriction","protocol/granite/derivation.html#granite-l2-chain-derivation-changes","protocol/granite/derivation.html#protocol-parameter-changes","protocol/granite/derivation.html#reduce-channel-timeout","protocol/holocene/overview.html#holocene-network-upgrade","protocol/holocene/overview.html#execution-layer","protocol/holocene/overview.html#consensus-layer","protocol/holocene/overview.html#smart-contracts","protocol/holocene/derivation.html#holocene-l2-chain-derivation-changes","protocol/holocene/derivation.html#holocene-derivation","protocol/holocene/derivation.html#summary","protocol/holocene/derivation.html#frame-queue","protocol/holocene/derivation.html#channel-bank","protocol/holocene/derivation.html#pruning","protocol/holocene/derivation.html#timeout","protocol/holocene/derivation.html#reading--frame-loading","protocol/holocene/derivation.html#span-batches","protocol/holocene/derivation.html#batch-queue","protocol/holocene/derivation.html#fast-channel-invalidation","protocol/holocene/derivation.html#engine-queue","protocol/holocene/derivation.html#attributes-builder","protocol/holocene/derivation.html#activation","protocol/holocene/derivation.html#rationale","protocol/holocene/derivation.html#strict-frame-and-batch-ordering","protocol/holocene/derivation.html#partial-span-batch-validity","protocol/holocene/derivation.html#fast-channel-invalidation-1","protocol/holocene/derivation.html#steady-block-derivation","protocol/holocene/derivation.html#less-defensive-protocol","protocol/holocene/derivation.html#security-and-implementation-considerations","protocol/holocene/derivation.html#reorgs","protocol/holocene/derivation.html#batcher-hardening","protocol/holocene/derivation.html#sync-start","protocol/holocene/exec-engine.html#l2-execution-engine","protocol/holocene/exec-engine.html#timestamp-activation","protocol/holocene/exec-engine.html#l2tol1messagepasser-storage-root-in-header","protocol/holocene/exec-engine.html#header-validity-rules","protocol/holocene/exec-engine.html#header-withdrawals-root","protocol/holocene/exec-engine.html#extended-payloadattributesv3","protocol/holocene/exec-engine.html#eip1559params-encoding","protocol/holocene/exec-engine.html#execution","protocol/holocene/exec-engine.html#rationale","protocol/holocene/exec-engine.html#eip1559params-in-header","protocol/holocene/exec-engine.html#header-validity-rules-1","protocol/holocene/exec-engine.html#encoding","protocol/holocene/exec-engine.html#rationale-1","protocol/holocene/predeploys.html#overview","protocol/holocene/predeploys.html#constants","protocol/holocene/predeploys.html#predeploys","protocol/holocene/predeploys.html#l1block","protocol/holocene/predeploys.html#feevault","protocol/holocene/predeploys.html#l2crossdomainmessenger","protocol/holocene/predeploys.html#l2erc721bridge","protocol/holocene/predeploys.html#l2standardbridge","protocol/holocene/predeploys.html#optimismmintableerc721factory","protocol/holocene/predeploys.html#security-considerations","protocol/holocene/predeploys.html#governancetoken","protocol/holocene/configurability.html#configurability","protocol/holocene/configurability.html#overview","protocol/holocene/configurability.html#constants","protocol/holocene/configurability.html#configtype","protocol/holocene/configurability.html#systemconfig","protocol/holocene/configurability.html#configupdate","protocol/holocene/configurability.html#initialization","protocol/holocene/configurability.html#modifying-eip-1559-parameters","protocol/holocene/configurability.html#interface","protocol/holocene/configurability.html#optimismportal","protocol/holocene/configurability.html#interface-1","governance/gov-token.html#governance-token","governance/gov-token.html#overview","governance/gov-token.html#token-minting","governance/gov-token.html#token-burning","governance/gov-token.html#voting-power","governance/gov-token.html#delegation","experimental/custom-gas-token.html#custom-gas-token","experimental/custom-gas-token.html#overview","experimental/custom-gas-token.html#constants","experimental/custom-gas-token.html#properties-of-a-gas-paying-token","experimental/custom-gas-token.html#automated-validation","experimental/custom-gas-token.html#configuring-the-gas-paying-token","experimental/custom-gas-token.html#contract-modifications","experimental/custom-gas-token.html#igastoken-interface","experimental/custom-gas-token.html#gas-token-aware","experimental/custom-gas-token.html#optimismportal","experimental/custom-gas-token.html#standardbridge","experimental/custom-gas-token.html#crossdomainmessenger","experimental/custom-gas-token.html#systemconfig","experimental/custom-gas-token.html#l1block","experimental/custom-gas-token.html#weth9","experimental/custom-gas-token.html#user-flow","experimental/custom-gas-token.html#when-eth-is-the-native-asset","experimental/custom-gas-token.html#when-an-erc20-token-is-the-native-asset","experimental/custom-gas-token.html#differences","experimental/custom-gas-token.html#upgrade","experimental/custom-gas-token.html#l1block-deployment","experimental/custom-gas-token.html#l2crossdomainmessenger-deployment","experimental/custom-gas-token.html#l2standardbridge-deployment","experimental/custom-gas-token.html#l1block-proxy-update","experimental/custom-gas-token.html#l2crossdomainmessenger-proxy-update","experimental/custom-gas-token.html#l2standardbridge-proxy-update","experimental/custom-gas-token.html#selection-of-ether_token_address","experimental/custom-gas-token.html#standard-config","experimental/custom-gas-token.html#fees","experimental/custom-gas-token.html#security-considerations","experimental/custom-gas-token.html#optimismportal-token-allowance","experimental/custom-gas-token.html#interoperability-support","experimental/custom-gas-token.html#wrapped-ether","experimental/alt-da.html#alt-da-mode","experimental/alt-da.html#overview","experimental/alt-da.html#input-commitment-submission","experimental/alt-da.html#da-server","experimental/alt-da.html#data-availability-challenge-contract","experimental/alt-da.html#parameters","experimental/alt-da.html#derivation","experimental/alt-da.html#fault-proof","experimental/alt-da.html#l2-input","experimental/alt-da.html#l1-challenge-status","experimental/alt-da.html#safety-and-finality","experimental/alt-da.html#security-considerations","interop/overview.html#interop","interop/overview.html#specifications","interop/dependency-set.html#the-dependency-set","interop/dependency-set.html#chain-id","interop/dependency-set.html#updating-the-dependency-set","interop/dependency-set.html#security-considerations","interop/dependency-set.html#layer-1-as-part-of-the-dependency-set","interop/messaging.html#messaging","interop/messaging.html#message","interop/messaging.html#message-payload","interop/messaging.html#message-identifier","interop/messaging.html#messaging-ends","interop/messaging.html#initiating-messages","interop/messaging.html#executing-messages","interop/messaging.html#messaging-invariants","interop/messaging.html#timestamp-invariant","interop/messaging.html#chainid-invariant","interop/messaging.html#message-expiry-invariant","interop/messaging.html#message-graph","interop/messaging.html#invalid-messages","interop/messaging.html#intra-block-messaging-cycles","interop/messaging.html#resolving-cross-chain-safety","interop/messaging.html#horizon-timestamp","interop/messaging.html#pruning-the-graph","interop/messaging.html#bounding-the-graph","interop/messaging.html#security-considerations","interop/messaging.html#cyclic-dependencies","interop/messaging.html#transitive-dependencies","interop/predeploys.html#predeploys","interop/predeploys.html#crossl2inbox","interop/predeploys.html#functions","interop/predeploys.html#interop-start-timestamp","interop/predeploys.html#executingmessage-event","interop/predeploys.html#reference-implementation","interop/predeploys.html#deposit-handling","interop/predeploys.html#identifier-getters","interop/predeploys.html#l2tol2crossdomainmessenger","interop/predeploys.html#relaymessage-invariants","interop/predeploys.html#sendexpire-invariants","interop/predeploys.html#relayexpire-invariants","interop/predeploys.html#message-versioning","interop/predeploys.html#no-native-support-for-cross-chain-ether-sends","interop/predeploys.html#interfaces","interop/predeploys.html#optimismsuperchainerc20factory","interop/predeploys.html#optimismsuperchainerc20","interop/predeploys.html#overview","interop/predeploys.html#functions-1","interop/predeploys.html#events","interop/predeploys.html#deployment-flow","interop/predeploys.html#beaconcontract","interop/predeploys.html#overview-1","interop/predeploys.html#l1block","interop/predeploys.html#static-configuration","interop/predeploys.html#dependency-set","interop/predeploys.html#deposit-context","interop/predeploys.html#isdeposit","interop/predeploys.html#optimismmintableerc20factory","interop/predeploys.html#optimismmintableerc20","interop/predeploys.html#updates","interop/predeploys.html#functions-2","interop/predeploys.html#events-1","interop/predeploys.html#l2standardbridge","interop/predeploys.html#updates-1","interop/predeploys.html#invariants","interop/predeploys.html#conversion-flow","interop/predeploys.html#superchainerc20bridge","interop/predeploys.html#overview-2","interop/predeploys.html#functions-3","interop/predeploys.html#events-2","interop/predeploys.html#diagram","interop/predeploys.html#invariants-1","interop/predeploys.html#security-considerations","interop/sequencer.html#sequencer","interop/sequencer.html#sequencer-policy","interop/sequencer.html#block-building","interop/sequencer.html#static-analysis","interop/sequencer.html#dependency-confirmations","interop/sequencer.html#sponsorship","interop/sequencer.html#security-considerations","interop/sequencer.html#cross-chain-message-latency","interop/verifier.html#verifier","interop/verifier.html#derivation-pipeline","interop/verifier.html#depositing-an-executing-message","interop/verifier.html#safety","interop/verifier.html#honest-verifier","interop/verifier.html#security-considerations","interop/verifier.html#forced-inclusion-of-cross-chain-messages","interop/verifier.html#reliance-on-history","interop/rollup-node-p2p.html#p2p-networking","interop/rollup-node-p2p.html#security-considerations","interop/fault-proof.html#fault-proof","interop/fault-proof.html#cascading-dependencies","interop/fault-proof.html#security-considerations","interop/upgrade.html#interop-network-upgrade","interop/upgrade.html#l1-attributes","interop/upgrade.html#l1-attributes-predeployed-contract","interop/upgrade.html#interop-l1block-upgrade","interop/upgrade.html#security-considerations","interop/token-bridging.html#token-bridging","interop/token-bridging.html#overview","interop/token-bridging.html#superchainerc20-standard","interop/token-bridging.html#properties","interop/token-bridging.html#interface","interop/token-bridging.html#superchainerc20bridge","interop/token-bridging.html#diagram","interop/token-bridging.html#implementation","interop/token-bridging.html#future-considerations","interop/token-bridging.html#cross-chain-transferfrom","interop/token-bridging.html#concatenated-action","interop/superchain-weth.html#superchain-weth","interop/superchain-weth.html#motivation-and-constraints","interop/superchain-weth.html#handling-native-assets-other-than-eth","interop/superchain-weth.html#minimizing-protocol-complexity","interop/superchain-weth.html#constants","interop/superchain-weth.html#superchainweth","interop/superchain-weth.html#invariants","interop/superchain-weth.html#ethliquidity","interop/superchain-weth.html#invariants-1","interop/derivation.html#derivation","interop/derivation.html#overview","interop/derivation.html#deposit-context","interop/derivation.html#security-considerations","interop/derivation.html#gas-considerations","interop/tx-pool.html#transaction-pool","interop/tx-pool.html#message-validation","interop/tx-pool.html#system-deposits-transaction-margin","interop/tx-pool.html#security-considerations","interop/tx-pool.html#mempool-denial-of-service","experimental/op-contracts-manager.html#op-contracts-manager","experimental/op-contracts-manager.html#deployment","experimental/op-contracts-manager.html#interface","experimental/op-contracts-manager.html#proxysol","experimental/op-contracts-manager.html#deploy","experimental/op-contracts-manager.html#getter-methods","experimental/op-contracts-manager.html#implementation","experimental/op-contracts-manager.html#batch-inbox-address","experimental/op-contracts-manager.html#contract-deployments","experimental/op-contracts-manager.html#security-considerations","experimental/op-contracts-manager.html#chain-id-source-of-truth","experimental/op-contracts-manager.html#chain-id-frontrunning","experimental/op-contracts-manager.html#chain-id-value","experimental/op-contracts-manager.html#proxy-admin-owner","experimental/op-contracts-manager.html#upgradeability-abi-changes","experimental/gov-token.html#governance-token","experimental/gov-token.html#overview","experimental/gov-token.html#hook-based-integration-with-governancedelegation","experimental/gov-token.html#token-minting","experimental/gov-token.html#token-burning","experimental/gov-token.html#voting-power","experimental/gov-token.html#delegation","glossary.html#glossary","glossary.html#general-terms","glossary.html#layer-1-l1","glossary.html#layer-2-l2","glossary.html#block","glossary.html#eoa","glossary.html#merkle-patricia-trie","glossary.html#chain-re-organization","glossary.html#predeployed-contract-predeploy","glossary.html#preinstalled-contract-preinstall","glossary.html#precompiled-contract-precompile","glossary.html#receipt","glossary.html#transaction-type","glossary.html#fork-choice-rule","glossary.html#priority-gas-auction","glossary.html#sequencing","glossary.html#sequencer","glossary.html#sequencing-window","glossary.html#sequencing-epoch","glossary.html#l1-origin","glossary.html#deposits","glossary.html#deposited-transaction","glossary.html#l1-attributes-deposited-transaction","glossary.html#user-deposited-transaction","glossary.html#depositing-call","glossary.html#depositing-transaction","glossary.html#depositor","glossary.html#deposited-transaction-type","glossary.html#deposit-contract","glossary.html#withdrawals","glossary.html#relayer","glossary.html#finalization-period","glossary.html#batch-submission","glossary.html#data-availability","glossary.html#data-availability-provider","glossary.html#sequencer-batch","glossary.html#channel","glossary.html#channel-frame","glossary.html#batcher","glossary.html#batcher-transaction","glossary.html#batch-submission-frequency","glossary.html#channel-timeout","glossary.html#l2-output-root-proposals","glossary.html#proposer","glossary.html#l2-chain-derivation","glossary.html#l2-derivation-inputs","glossary.html#system-configuration","glossary.html#payload-attributes","glossary.html#l2-genesis-block","glossary.html#l2-chain-inception","glossary.html#safe-l2-block","glossary.html#safe-l2-head","glossary.html#unsafe-l2-block","glossary.html#unsafe-l2-head","glossary.html#unsafe-block-consolidation","glossary.html#finalized-l2-head","glossary.html#other-l2-chain-concepts","glossary.html#address-aliasing","glossary.html#rollup-node","glossary.html#rollup-driver","glossary.html#l1-attributes-predeployed-contract","glossary.html#l2-output-root","glossary.html#l2-output-oracle-contract","glossary.html#validator","glossary.html#fault-proof","glossary.html#time-slot","glossary.html#block-time","glossary.html#unsafe-sync","glossary.html#execution-engine-concepts","glossary.html#execution-engine"],"index":{"documentStore":{"docInfo":{"0":{"body":7,"breadcrumbs":4,"title":3},"1":{"body":51,"breadcrumbs":2,"title":1},"10":{"body":17,"breadcrumbs":3,"title":2},"100":{"body":260,"breadcrumbs":7,"title":1},"101":{"body":81,"breadcrumbs":7,"title":1},"102":{"body":7,"breadcrumbs":7,"title":1},"103":{"body":30,"breadcrumbs":7,"title":1},"104":{"body":9,"breadcrumbs":7,"title":1},"105":{"body":36,"breadcrumbs":7,"title":1},"106":{"body":72,"breadcrumbs":7,"title":1},"107":{"body":99,"breadcrumbs":7,"title":1},"108":{"body":53,"breadcrumbs":7,"title":1},"109":{"body":99,"breadcrumbs":9,"title":3},"11":{"body":33,"breadcrumbs":2,"title":1},"110":{"body":47,"breadcrumbs":9,"title":3},"111":{"body":97,"breadcrumbs":10,"title":4},"112":{"body":80,"breadcrumbs":10,"title":4},"113":{"body":31,"breadcrumbs":8,"title":2},"114":{"body":20,"breadcrumbs":9,"title":3},"115":{"body":26,"breadcrumbs":7,"title":1},"116":{"body":26,"breadcrumbs":7,"title":1},"117":{"body":85,"breadcrumbs":7,"title":1},"118":{"body":13,"breadcrumbs":10,"title":4},"119":{"body":112,"breadcrumbs":7,"title":1},"12":{"body":30,"breadcrumbs":2,"title":1},"120":{"body":57,"breadcrumbs":9,"title":3},"121":{"body":61,"breadcrumbs":9,"title":3},"122":{"body":60,"breadcrumbs":13,"title":4},"123":{"body":143,"breadcrumbs":10,"title":1},"124":{"body":0,"breadcrumbs":11,"title":2},"125":{"body":69,"breadcrumbs":10,"title":1},"126":{"body":149,"breadcrumbs":10,"title":1},"127":{"body":576,"breadcrumbs":10,"title":1},"128":{"body":9,"breadcrumbs":11,"title":2},"129":{"body":5,"breadcrumbs":10,"title":1},"13":{"body":29,"breadcrumbs":2,"title":1},"130":{"body":4,"breadcrumbs":10,"title":1},"131":{"body":4,"breadcrumbs":10,"title":1},"132":{"body":71,"breadcrumbs":11,"title":2},"133":{"body":42,"breadcrumbs":11,"title":2},"134":{"body":233,"breadcrumbs":11,"title":2},"135":{"body":167,"breadcrumbs":11,"title":2},"136":{"body":255,"breadcrumbs":10,"title":1},"137":{"body":130,"breadcrumbs":11,"title":4},"138":{"body":420,"breadcrumbs":8,"title":1},"139":{"body":59,"breadcrumbs":10,"title":3},"14":{"body":84,"breadcrumbs":3,"title":2},"140":{"body":49,"breadcrumbs":9,"title":2},"141":{"body":0,"breadcrumbs":9,"title":2},"142":{"body":147,"breadcrumbs":11,"title":4},"143":{"body":478,"breadcrumbs":11,"title":4},"144":{"body":64,"breadcrumbs":10,"title":3},"145":{"body":115,"breadcrumbs":9,"title":2},"146":{"body":133,"breadcrumbs":9,"title":2},"147":{"body":120,"breadcrumbs":9,"title":2},"148":{"body":33,"breadcrumbs":8,"title":1},"149":{"body":143,"breadcrumbs":11,"title":4},"15":{"body":18,"breadcrumbs":2,"title":1},"150":{"body":47,"breadcrumbs":9,"title":2},"151":{"body":68,"breadcrumbs":9,"title":2},"152":{"body":20,"breadcrumbs":9,"title":2},"153":{"body":311,"breadcrumbs":9,"title":2},"154":{"body":19,"breadcrumbs":11,"title":4},"155":{"body":480,"breadcrumbs":9,"title":2},"156":{"body":57,"breadcrumbs":10,"title":3},"157":{"body":874,"breadcrumbs":9,"title":2},"158":{"body":581,"breadcrumbs":9,"title":2},"159":{"body":43,"breadcrumbs":10,"title":3},"16":{"body":103,"breadcrumbs":2,"title":1},"160":{"body":140,"breadcrumbs":10,"title":3},"161":{"body":700,"breadcrumbs":11,"title":4},"162":{"body":65,"breadcrumbs":11,"title":4},"163":{"body":3,"breadcrumbs":8,"title":2},"164":{"body":116,"breadcrumbs":7,"title":1},"165":{"body":114,"breadcrumbs":7,"title":2},"166":{"body":77,"breadcrumbs":6,"title":1},"167":{"body":52,"breadcrumbs":8,"title":3},"168":{"body":548,"breadcrumbs":9,"title":4},"169":{"body":51,"breadcrumbs":6,"title":1},"17":{"body":62,"breadcrumbs":2,"title":1},"170":{"body":215,"breadcrumbs":6,"title":1},"171":{"body":128,"breadcrumbs":8,"title":3},"172":{"body":55,"breadcrumbs":8,"title":3},"173":{"body":146,"breadcrumbs":6,"title":1},"174":{"body":252,"breadcrumbs":7,"title":2},"175":{"body":142,"breadcrumbs":6,"title":1},"176":{"body":190,"breadcrumbs":9,"title":4},"177":{"body":55,"breadcrumbs":7,"title":2},"178":{"body":104,"breadcrumbs":8,"title":3},"179":{"body":88,"breadcrumbs":10,"title":5},"18":{"body":0,"breadcrumbs":4,"title":3},"180":{"body":30,"breadcrumbs":14,"title":5},"181":{"body":75,"breadcrumbs":10,"title":1},"182":{"body":116,"breadcrumbs":10,"title":1},"183":{"body":51,"breadcrumbs":11,"title":2},"184":{"body":59,"breadcrumbs":10,"title":1},"185":{"body":82,"breadcrumbs":10,"title":1},"186":{"body":63,"breadcrumbs":11,"title":2},"187":{"body":165,"breadcrumbs":10,"title":1},"188":{"body":126,"breadcrumbs":10,"title":1},"189":{"body":26,"breadcrumbs":11,"title":2},"19":{"body":93,"breadcrumbs":4,"title":3},"190":{"body":22,"breadcrumbs":11,"title":2},"191":{"body":162,"breadcrumbs":12,"title":3},"192":{"body":68,"breadcrumbs":10,"title":1},"193":{"body":0,"breadcrumbs":11,"title":2},"194":{"body":147,"breadcrumbs":11,"title":2},"195":{"body":121,"breadcrumbs":11,"title":2},"196":{"body":19,"breadcrumbs":11,"title":3},"197":{"body":8,"breadcrumbs":14,"title":3},"198":{"body":74,"breadcrumbs":12,"title":1},"199":{"body":179,"breadcrumbs":12,"title":1},"2":{"body":28,"breadcrumbs":3,"title":2},"20":{"body":141,"breadcrumbs":2,"title":1},"200":{"body":614,"breadcrumbs":13,"title":2},"201":{"body":348,"breadcrumbs":13,"title":2},"202":{"body":52,"breadcrumbs":14,"title":3},"203":{"body":79,"breadcrumbs":12,"title":1},"204":{"body":0,"breadcrumbs":12,"title":1},"205":{"body":44,"breadcrumbs":14,"title":3},"206":{"body":31,"breadcrumbs":12,"title":1},"207":{"body":25,"breadcrumbs":13,"title":2},"208":{"body":64,"breadcrumbs":12,"title":1},"209":{"body":78,"breadcrumbs":13,"title":2},"21":{"body":19,"breadcrumbs":3,"title":2},"210":{"body":29,"breadcrumbs":14,"title":3},"211":{"body":34,"breadcrumbs":12,"title":1},"212":{"body":80,"breadcrumbs":12,"title":1},"213":{"body":68,"breadcrumbs":13,"title":2},"214":{"body":112,"breadcrumbs":12,"title":1},"215":{"body":12,"breadcrumbs":12,"title":1},"216":{"body":15,"breadcrumbs":12,"title":1},"217":{"body":92,"breadcrumbs":13,"title":2},"218":{"body":22,"breadcrumbs":14,"title":3},"219":{"body":32,"breadcrumbs":12,"title":1},"22":{"body":72,"breadcrumbs":5,"title":2},"220":{"body":216,"breadcrumbs":12,"title":1},"221":{"body":110,"breadcrumbs":15,"title":4},"222":{"body":122,"breadcrumbs":12,"title":1},"223":{"body":123,"breadcrumbs":13,"title":2},"224":{"body":428,"breadcrumbs":13,"title":2},"225":{"body":58,"breadcrumbs":13,"title":2},"226":{"body":128,"breadcrumbs":13,"title":2},"227":{"body":229,"breadcrumbs":12,"title":1},"228":{"body":87,"breadcrumbs":12,"title":1},"229":{"body":12,"breadcrumbs":18,"title":5},"23":{"body":98,"breadcrumbs":6,"title":3},"230":{"body":90,"breadcrumbs":14,"title":1},"231":{"body":39,"breadcrumbs":14,"title":1},"232":{"body":93,"breadcrumbs":17,"title":4},"233":{"body":52,"breadcrumbs":14,"title":1},"234":{"body":65,"breadcrumbs":14,"title":1},"235":{"body":11,"breadcrumbs":14,"title":1},"236":{"body":64,"breadcrumbs":14,"title":1},"237":{"body":31,"breadcrumbs":15,"title":2},"238":{"body":65,"breadcrumbs":14,"title":1},"239":{"body":60,"breadcrumbs":14,"title":1},"24":{"body":0,"breadcrumbs":5,"title":2},"240":{"body":42,"breadcrumbs":15,"title":2},"241":{"body":53,"breadcrumbs":16,"title":3},"242":{"body":15,"breadcrumbs":17,"title":4},"243":{"body":27,"breadcrumbs":15,"title":2},"244":{"body":37,"breadcrumbs":16,"title":3},"245":{"body":90,"breadcrumbs":15,"title":2},"246":{"body":23,"breadcrumbs":16,"title":3},"247":{"body":31,"breadcrumbs":14,"title":1},"248":{"body":367,"breadcrumbs":14,"title":1},"249":{"body":54,"breadcrumbs":12,"title":2},"25":{"body":394,"breadcrumbs":7,"title":4},"250":{"body":27,"breadcrumbs":11,"title":1},"251":{"body":151,"breadcrumbs":12,"title":2},"252":{"body":0,"breadcrumbs":14,"title":4},"253":{"body":10,"breadcrumbs":12,"title":2},"254":{"body":39,"breadcrumbs":13,"title":3},"255":{"body":42,"breadcrumbs":12,"title":2},"256":{"body":96,"breadcrumbs":12,"title":2},"257":{"body":168,"breadcrumbs":12,"title":2},"258":{"body":122,"breadcrumbs":12,"title":2},"259":{"body":168,"breadcrumbs":12,"title":2},"26":{"body":251,"breadcrumbs":7,"title":4},"260":{"body":23,"breadcrumbs":12,"title":2},"261":{"body":43,"breadcrumbs":12,"title":2},"262":{"body":12,"breadcrumbs":12,"title":2},"263":{"body":43,"breadcrumbs":11,"title":1},"264":{"body":4,"breadcrumbs":5,"title":1},"265":{"body":61,"breadcrumbs":5,"title":1},"266":{"body":35,"breadcrumbs":5,"title":1},"267":{"body":24,"breadcrumbs":5,"title":1},"268":{"body":168,"breadcrumbs":5,"title":1},"269":{"body":71,"breadcrumbs":5,"title":1},"27":{"body":70,"breadcrumbs":6,"title":3},"270":{"body":33,"breadcrumbs":5,"title":1},"271":{"body":48,"breadcrumbs":5,"title":1},"272":{"body":41,"breadcrumbs":5,"title":1},"273":{"body":19,"breadcrumbs":5,"title":1},"274":{"body":59,"breadcrumbs":5,"title":1},"275":{"body":84,"breadcrumbs":5,"title":1},"276":{"body":30,"breadcrumbs":5,"title":1},"277":{"body":141,"breadcrumbs":5,"title":1},"278":{"body":16,"breadcrumbs":5,"title":1},"279":{"body":18,"breadcrumbs":5,"title":1},"28":{"body":142,"breadcrumbs":6,"title":3},"280":{"body":29,"breadcrumbs":5,"title":1},"281":{"body":43,"breadcrumbs":5,"title":1},"282":{"body":14,"breadcrumbs":5,"title":1},"283":{"body":25,"breadcrumbs":5,"title":1},"284":{"body":21,"breadcrumbs":5,"title":1},"285":{"body":13,"breadcrumbs":5,"title":1},"286":{"body":10,"breadcrumbs":5,"title":1},"287":{"body":18,"breadcrumbs":7,"title":3},"288":{"body":32,"breadcrumbs":5,"title":1},"289":{"body":96,"breadcrumbs":5,"title":1},"29":{"body":56,"breadcrumbs":5,"title":2},"290":{"body":18,"breadcrumbs":5,"title":1},"291":{"body":16,"breadcrumbs":5,"title":1},"292":{"body":8,"breadcrumbs":5,"title":1},"293":{"body":9,"breadcrumbs":5,"title":1},"294":{"body":51,"breadcrumbs":5,"title":1},"295":{"body":24,"breadcrumbs":5,"title":1},"296":{"body":127,"breadcrumbs":5,"title":1},"297":{"body":26,"breadcrumbs":5,"title":1},"298":{"body":87,"breadcrumbs":8,"title":4},"299":{"body":22,"breadcrumbs":5,"title":1},"3":{"body":17,"breadcrumbs":3,"title":2},"30":{"body":0,"breadcrumbs":6,"title":3},"300":{"body":12,"breadcrumbs":8,"title":4},"301":{"body":14,"breadcrumbs":8,"title":4},"302":{"body":12,"breadcrumbs":8,"title":4},"303":{"body":14,"breadcrumbs":8,"title":4},"304":{"body":13,"breadcrumbs":8,"title":2},"305":{"body":14,"breadcrumbs":7,"title":1},"306":{"body":25,"breadcrumbs":8,"title":2},"307":{"body":29,"breadcrumbs":9,"title":3},"308":{"body":70,"breadcrumbs":7,"title":1},"309":{"body":52,"breadcrumbs":8,"title":2},"31":{"body":69,"breadcrumbs":4,"title":1},"310":{"body":57,"breadcrumbs":7,"title":1},"311":{"body":123,"breadcrumbs":8,"title":2},"312":{"body":326,"breadcrumbs":9,"title":3},"313":{"body":36,"breadcrumbs":9,"title":3},"314":{"body":42,"breadcrumbs":8,"title":2},"315":{"body":88,"breadcrumbs":9,"title":3},"316":{"body":47,"breadcrumbs":9,"title":3},"317":{"body":58,"breadcrumbs":8,"title":2},"318":{"body":72,"breadcrumbs":12,"title":6},"319":{"body":100,"breadcrumbs":11,"title":5},"32":{"body":326,"breadcrumbs":5,"title":2},"320":{"body":130,"breadcrumbs":10,"title":4},"321":{"body":0,"breadcrumbs":10,"title":4},"322":{"body":49,"breadcrumbs":8,"title":2},"323":{"body":31,"breadcrumbs":7,"title":2},"324":{"body":19,"breadcrumbs":6,"title":1},"325":{"body":8,"breadcrumbs":10,"title":5},"326":{"body":43,"breadcrumbs":7,"title":2},"327":{"body":287,"breadcrumbs":6,"title":1},"328":{"body":51,"breadcrumbs":7,"title":2},"329":{"body":51,"breadcrumbs":7,"title":2},"33":{"body":139,"breadcrumbs":5,"title":2},"330":{"body":33,"breadcrumbs":8,"title":3},"331":{"body":219,"breadcrumbs":8,"title":3},"332":{"body":256,"breadcrumbs":7,"title":3},"333":{"body":0,"breadcrumbs":6,"title":2},"334":{"body":26,"breadcrumbs":7,"title":3},"335":{"body":22,"breadcrumbs":6,"title":2},"336":{"body":29,"breadcrumbs":6,"title":2},"337":{"body":41,"breadcrumbs":7,"title":3},"338":{"body":34,"breadcrumbs":7,"title":3},"339":{"body":31,"breadcrumbs":7,"title":3},"34":{"body":6,"breadcrumbs":6,"title":2},"340":{"body":25,"breadcrumbs":8,"title":4},"341":{"body":32,"breadcrumbs":8,"title":4},"342":{"body":26,"breadcrumbs":8,"title":4},"343":{"body":27,"breadcrumbs":7,"title":3},"344":{"body":27,"breadcrumbs":7,"title":3},"345":{"body":36,"breadcrumbs":9,"title":5},"346":{"body":28,"breadcrumbs":9,"title":5},"347":{"body":34,"breadcrumbs":8,"title":4},"348":{"body":30,"breadcrumbs":8,"title":4},"349":{"body":18,"breadcrumbs":9,"title":5},"35":{"body":186,"breadcrumbs":5,"title":1},"350":{"body":20,"breadcrumbs":6,"title":2},"351":{"body":31,"breadcrumbs":6,"title":2},"352":{"body":29,"breadcrumbs":6,"title":2},"353":{"body":24,"breadcrumbs":7,"title":3},"354":{"body":26,"breadcrumbs":6,"title":2},"355":{"body":48,"breadcrumbs":7,"title":3},"356":{"body":19,"breadcrumbs":6,"title":2},"357":{"body":35,"breadcrumbs":6,"title":2},"358":{"body":23,"breadcrumbs":6,"title":2},"359":{"body":18,"breadcrumbs":6,"title":2},"36":{"body":24,"breadcrumbs":6,"title":2},"360":{"body":0,"breadcrumbs":6,"title":2},"361":{"body":34,"breadcrumbs":7,"title":3},"362":{"body":48,"breadcrumbs":7,"title":3},"363":{"body":39,"breadcrumbs":6,"title":2},"364":{"body":0,"breadcrumbs":6,"title":2},"365":{"body":52,"breadcrumbs":7,"title":3},"366":{"body":20,"breadcrumbs":7,"title":3},"367":{"body":31,"breadcrumbs":7,"title":3},"368":{"body":37,"breadcrumbs":7,"title":3},"369":{"body":83,"breadcrumbs":7,"title":3},"37":{"body":8,"breadcrumbs":5,"title":1},"370":{"body":0,"breadcrumbs":6,"title":2},"371":{"body":15,"breadcrumbs":7,"title":3},"372":{"body":33,"breadcrumbs":6,"title":2},"373":{"body":37,"breadcrumbs":6,"title":2},"374":{"body":39,"breadcrumbs":6,"title":2},"375":{"body":28,"breadcrumbs":9,"title":5},"376":{"body":128,"breadcrumbs":8,"title":3},"377":{"body":6,"breadcrumbs":7,"title":2},"378":{"body":178,"breadcrumbs":8,"title":3},"379":{"body":58,"breadcrumbs":10,"title":5},"38":{"body":17,"breadcrumbs":8,"title":3},"380":{"body":52,"breadcrumbs":10,"title":5},"381":{"body":94,"breadcrumbs":7,"title":2},"382":{"body":52,"breadcrumbs":7,"title":2},"383":{"body":51,"breadcrumbs":9,"title":4},"384":{"body":23,"breadcrumbs":6,"title":1},"385":{"body":126,"breadcrumbs":8,"title":3},"386":{"body":29,"breadcrumbs":11,"title":6},"387":{"body":0,"breadcrumbs":7,"title":2},"388":{"body":22,"breadcrumbs":10,"title":5},"389":{"body":62,"breadcrumbs":9,"title":4},"39":{"body":186,"breadcrumbs":6,"title":1},"390":{"body":76,"breadcrumbs":9,"title":4},"391":{"body":14,"breadcrumbs":13,"title":4},"392":{"body":20,"breadcrumbs":10,"title":1},"393":{"body":7,"breadcrumbs":12,"title":3},"394":{"body":82,"breadcrumbs":12,"title":3},"395":{"body":177,"breadcrumbs":11,"title":2},"396":{"body":134,"breadcrumbs":12,"title":3},"397":{"body":3,"breadcrumbs":7,"title":1},"398":{"body":158,"breadcrumbs":7,"title":1},"399":{"body":40,"breadcrumbs":7,"title":1},"4":{"body":29,"breadcrumbs":2,"title":1},"40":{"body":75,"breadcrumbs":7,"title":2},"400":{"body":51,"breadcrumbs":8,"title":2},"401":{"body":3,"breadcrumbs":8,"title":2},"402":{"body":16,"breadcrumbs":7,"title":1},"403":{"body":9,"breadcrumbs":8,"title":2},"404":{"body":70,"breadcrumbs":10,"title":2},"405":{"body":150,"breadcrumbs":9,"title":1},"406":{"body":314,"breadcrumbs":11,"title":3},"407":{"body":38,"breadcrumbs":12,"title":4},"408":{"body":74,"breadcrumbs":12,"title":4},"409":{"body":41,"breadcrumbs":12,"title":4},"41":{"body":13,"breadcrumbs":6,"title":1},"410":{"body":0,"breadcrumbs":10,"title":2},"411":{"body":27,"breadcrumbs":13,"title":5},"412":{"body":19,"breadcrumbs":12,"title":4},"413":{"body":20,"breadcrumbs":13,"title":5},"414":{"body":24,"breadcrumbs":13,"title":5},"415":{"body":44,"breadcrumbs":13,"title":5},"416":{"body":64,"breadcrumbs":13,"title":5},"417":{"body":32,"breadcrumbs":14,"title":6},"418":{"body":75,"breadcrumbs":11,"title":3},"419":{"body":142,"breadcrumbs":12,"title":4},"42":{"body":36,"breadcrumbs":7,"title":2},"420":{"body":0,"breadcrumbs":9,"title":1},"421":{"body":18,"breadcrumbs":12,"title":4},"422":{"body":482,"breadcrumbs":10,"title":2},"423":{"body":101,"breadcrumbs":9,"title":1},"424":{"body":18,"breadcrumbs":9,"title":3},"425":{"body":80,"breadcrumbs":8,"title":2},"426":{"body":30,"breadcrumbs":8,"title":2},"427":{"body":7,"breadcrumbs":8,"title":1},"428":{"body":110,"breadcrumbs":10,"title":3},"429":{"body":279,"breadcrumbs":9,"title":2},"43":{"body":6,"breadcrumbs":8,"title":3},"430":{"body":10,"breadcrumbs":11,"title":3},"431":{"body":203,"breadcrumbs":9,"title":1},"432":{"body":116,"breadcrumbs":12,"title":4},"433":{"body":111,"breadcrumbs":11,"title":3},"434":{"body":6,"breadcrumbs":9,"title":3},"435":{"body":22,"breadcrumbs":8,"title":2},"436":{"body":16,"breadcrumbs":8,"title":2},"437":{"body":27,"breadcrumbs":11,"title":3},"438":{"body":0,"breadcrumbs":9,"title":1},"439":{"body":266,"breadcrumbs":14,"title":6},"44":{"body":8,"breadcrumbs":8,"title":3},"440":{"body":24,"breadcrumbs":12,"title":4},"441":{"body":35,"breadcrumbs":12,"title":5},"442":{"body":35,"breadcrumbs":10,"title":3},"443":{"body":51,"breadcrumbs":9,"title":2},"444":{"body":34,"breadcrumbs":11,"title":4},"445":{"body":53,"breadcrumbs":8,"title":1},"446":{"body":66,"breadcrumbs":9,"title":2},"447":{"body":57,"breadcrumbs":10,"title":3},"448":{"body":110,"breadcrumbs":8,"title":1},"449":{"body":115,"breadcrumbs":9,"title":2},"45":{"body":45,"breadcrumbs":8,"title":3},"450":{"body":75,"breadcrumbs":10,"title":3},"451":{"body":43,"breadcrumbs":11,"title":4},"452":{"body":106,"breadcrumbs":9,"title":2},"453":{"body":75,"breadcrumbs":10,"title":3},"454":{"body":66,"breadcrumbs":10,"title":3},"455":{"body":7,"breadcrumbs":8,"title":1},"456":{"body":130,"breadcrumbs":8,"title":1},"457":{"body":91,"breadcrumbs":11,"title":4},"458":{"body":6,"breadcrumbs":9,"title":3},"459":{"body":5,"breadcrumbs":8,"title":2},"46":{"body":64,"breadcrumbs":6,"title":1},"460":{"body":4,"breadcrumbs":8,"title":2},"461":{"body":8,"breadcrumbs":11,"title":3},"462":{"body":0,"breadcrumbs":10,"title":2},"463":{"body":25,"breadcrumbs":12,"title":4},"464":{"body":8,"breadcrumbs":12,"title":5},"465":{"body":20,"breadcrumbs":10,"title":3},"466":{"body":18,"breadcrumbs":10,"title":3},"467":{"body":12,"breadcrumbs":9,"title":3},"468":{"body":4,"breadcrumbs":8,"title":2},"469":{"body":2,"breadcrumbs":8,"title":2},"47":{"body":40,"breadcrumbs":6,"title":1},"470":{"body":2,"breadcrumbs":8,"title":2},"471":{"body":52,"breadcrumbs":12,"title":5},"472":{"body":0,"breadcrumbs":9,"title":2},"473":{"body":114,"breadcrumbs":8,"title":1},"474":{"body":174,"breadcrumbs":9,"title":2},"475":{"body":13,"breadcrumbs":9,"title":2},"476":{"body":32,"breadcrumbs":8,"title":1},"477":{"body":6,"breadcrumbs":8,"title":1},"478":{"body":77,"breadcrumbs":10,"title":3},"479":{"body":167,"breadcrumbs":9,"title":2},"48":{"body":205,"breadcrumbs":8,"title":3},"480":{"body":83,"breadcrumbs":9,"title":2},"481":{"body":39,"breadcrumbs":10,"title":3},"482":{"body":40,"breadcrumbs":9,"title":2},"483":{"body":72,"breadcrumbs":9,"title":2},"484":{"body":102,"breadcrumbs":8,"title":1},"485":{"body":0,"breadcrumbs":8,"title":1},"486":{"body":65,"breadcrumbs":11,"title":4},"487":{"body":59,"breadcrumbs":11,"title":4},"488":{"body":38,"breadcrumbs":10,"title":3},"489":{"body":54,"breadcrumbs":10,"title":3},"49":{"body":114,"breadcrumbs":8,"title":3},"490":{"body":70,"breadcrumbs":10,"title":3},"491":{"body":0,"breadcrumbs":10,"title":3},"492":{"body":85,"breadcrumbs":8,"title":1},"493":{"body":186,"breadcrumbs":9,"title":2},"494":{"body":180,"breadcrumbs":9,"title":2},"495":{"body":34,"breadcrumbs":11,"title":3},"496":{"body":15,"breadcrumbs":10,"title":2},"497":{"body":30,"breadcrumbs":12,"title":4},"498":{"body":40,"breadcrumbs":11,"title":3},"499":{"body":155,"breadcrumbs":11,"title":3},"5":{"body":40,"breadcrumbs":2,"title":1},"50":{"body":57,"breadcrumbs":8,"title":3},"500":{"body":33,"breadcrumbs":10,"title":2},"501":{"body":16,"breadcrumbs":10,"title":2},"502":{"body":45,"breadcrumbs":9,"title":1},"503":{"body":31,"breadcrumbs":9,"title":1},"504":{"body":13,"breadcrumbs":10,"title":2},"505":{"body":23,"breadcrumbs":11,"title":3},"506":{"body":6,"breadcrumbs":9,"title":1},"507":{"body":53,"breadcrumbs":9,"title":1},"508":{"body":53,"breadcrumbs":8,"title":1},"509":{"body":89,"breadcrumbs":8,"title":1},"51":{"body":24,"breadcrumbs":9,"title":4},"510":{"body":65,"breadcrumbs":8,"title":1},"511":{"body":149,"breadcrumbs":8,"title":1},"512":{"body":37,"breadcrumbs":8,"title":1},"513":{"body":11,"breadcrumbs":8,"title":1},"514":{"body":11,"breadcrumbs":8,"title":1},"515":{"body":11,"breadcrumbs":8,"title":1},"516":{"body":11,"breadcrumbs":8,"title":1},"517":{"body":0,"breadcrumbs":9,"title":2},"518":{"body":9,"breadcrumbs":8,"title":1},"519":{"body":28,"breadcrumbs":8,"title":1},"52":{"body":370,"breadcrumbs":6,"title":1},"520":{"body":7,"breadcrumbs":8,"title":1},"521":{"body":0,"breadcrumbs":8,"title":1},"522":{"body":58,"breadcrumbs":8,"title":1},"523":{"body":0,"breadcrumbs":8,"title":1},"524":{"body":56,"breadcrumbs":8,"title":1},"525":{"body":28,"breadcrumbs":8,"title":1},"526":{"body":15,"breadcrumbs":11,"title":4},"527":{"body":84,"breadcrumbs":8,"title":1},"528":{"body":7,"breadcrumbs":8,"title":1},"529":{"body":53,"breadcrumbs":8,"title":1},"53":{"body":146,"breadcrumbs":7,"title":2},"530":{"body":15,"breadcrumbs":5,"title":2},"531":{"body":49,"breadcrumbs":4,"title":1},"532":{"body":26,"breadcrumbs":5,"title":2},"533":{"body":25,"breadcrumbs":5,"title":2},"534":{"body":94,"breadcrumbs":5,"title":2},"535":{"body":37,"breadcrumbs":4,"title":1},"536":{"body":73,"breadcrumbs":7,"title":3},"537":{"body":83,"breadcrumbs":5,"title":1},"538":{"body":50,"breadcrumbs":5,"title":1},"539":{"body":77,"breadcrumbs":8,"title":4},"54":{"body":70,"breadcrumbs":9,"title":4},"540":{"body":50,"breadcrumbs":6,"title":2},"541":{"body":146,"breadcrumbs":8,"title":4},"542":{"body":0,"breadcrumbs":6,"title":2},"543":{"body":80,"breadcrumbs":6,"title":2},"544":{"body":20,"breadcrumbs":7,"title":3},"545":{"body":188,"breadcrumbs":5,"title":1},"546":{"body":65,"breadcrumbs":5,"title":1},"547":{"body":90,"breadcrumbs":5,"title":1},"548":{"body":85,"breadcrumbs":5,"title":1},"549":{"body":54,"breadcrumbs":5,"title":1},"55":{"body":25,"breadcrumbs":10,"title":5},"550":{"body":23,"breadcrumbs":5,"title":1},"551":{"body":39,"breadcrumbs":6,"title":2},"552":{"body":72,"breadcrumbs":7,"title":3},"553":{"body":86,"breadcrumbs":8,"title":4},"554":{"body":26,"breadcrumbs":5,"title":1},"555":{"body":146,"breadcrumbs":5,"title":1},"556":{"body":12,"breadcrumbs":6,"title":2},"557":{"body":12,"breadcrumbs":6,"title":2},"558":{"body":12,"breadcrumbs":6,"title":2},"559":{"body":12,"breadcrumbs":7,"title":3},"56":{"body":17,"breadcrumbs":8,"title":3},"560":{"body":12,"breadcrumbs":7,"title":3},"561":{"body":12,"breadcrumbs":7,"title":3},"562":{"body":17,"breadcrumbs":6,"title":2},"563":{"body":16,"breadcrumbs":6,"title":2},"564":{"body":47,"breadcrumbs":5,"title":1},"565":{"body":0,"breadcrumbs":6,"title":2},"566":{"body":25,"breadcrumbs":7,"title":3},"567":{"body":37,"breadcrumbs":6,"title":2},"568":{"body":17,"breadcrumbs":6,"title":2},"569":{"body":48,"breadcrumbs":6,"title":3},"57":{"body":19,"breadcrumbs":9,"title":4},"570":{"body":73,"breadcrumbs":4,"title":1},"571":{"body":194,"breadcrumbs":6,"title":3},"572":{"body":113,"breadcrumbs":5,"title":2},"573":{"body":0,"breadcrumbs":7,"title":4},"574":{"body":356,"breadcrumbs":4,"title":1},"575":{"body":393,"breadcrumbs":4,"title":1},"576":{"body":21,"breadcrumbs":5,"title":2},"577":{"body":7,"breadcrumbs":6,"title":3},"578":{"body":9,"breadcrumbs":8,"title":5},"579":{"body":125,"breadcrumbs":5,"title":2},"58":{"body":134,"breadcrumbs":9,"title":4},"580":{"body":63,"breadcrumbs":5,"title":2},"581":{"body":165,"breadcrumbs":3,"title":1},"582":{"body":78,"breadcrumbs":3,"title":1},"583":{"body":142,"breadcrumbs":6,"title":2},"584":{"body":69,"breadcrumbs":6,"title":2},"585":{"body":45,"breadcrumbs":7,"title":3},"586":{"body":0,"breadcrumbs":6,"title":2},"587":{"body":46,"breadcrumbs":9,"title":5},"588":{"body":50,"breadcrumbs":4,"title":1},"589":{"body":6,"breadcrumbs":4,"title":1},"59":{"body":92,"breadcrumbs":8,"title":3},"590":{"body":37,"breadcrumbs":5,"title":2},"591":{"body":121,"breadcrumbs":5,"title":2},"592":{"body":0,"breadcrumbs":5,"title":2},"593":{"body":43,"breadcrumbs":5,"title":2},"594":{"body":77,"breadcrumbs":5,"title":2},"595":{"body":41,"breadcrumbs":5,"title":2},"596":{"body":30,"breadcrumbs":5,"title":2},"597":{"body":21,"breadcrumbs":5,"title":2},"598":{"body":59,"breadcrumbs":6,"title":3},"599":{"body":25,"breadcrumbs":5,"title":2},"6":{"body":0,"breadcrumbs":2,"title":1},"60":{"body":121,"breadcrumbs":7,"title":2},"600":{"body":84,"breadcrumbs":5,"title":2},"601":{"body":28,"breadcrumbs":7,"title":4},"602":{"body":64,"breadcrumbs":7,"title":4},"603":{"body":15,"breadcrumbs":5,"title":2},"604":{"body":62,"breadcrumbs":5,"title":2},"605":{"body":67,"breadcrumbs":5,"title":2},"606":{"body":0,"breadcrumbs":5,"title":2},"607":{"body":27,"breadcrumbs":5,"title":2},"608":{"body":20,"breadcrumbs":5,"title":2},"609":{"body":118,"breadcrumbs":4,"title":1},"61":{"body":35,"breadcrumbs":6,"title":1},"610":{"body":25,"breadcrumbs":4,"title":1},"611":{"body":141,"breadcrumbs":4,"title":1},"612":{"body":67,"breadcrumbs":6,"title":3},"613":{"body":50,"breadcrumbs":5,"title":2},"614":{"body":175,"breadcrumbs":5,"title":2},"615":{"body":31,"breadcrumbs":5,"title":2},"616":{"body":11,"breadcrumbs":5,"title":2},"617":{"body":45,"breadcrumbs":4,"title":1},"618":{"body":9,"breadcrumbs":5,"title":2},"619":{"body":21,"breadcrumbs":5,"title":2},"62":{"body":132,"breadcrumbs":6,"title":1},"620":{"body":20,"breadcrumbs":5,"title":2},"621":{"body":17,"breadcrumbs":5,"title":2},"622":{"body":26,"breadcrumbs":9,"title":6},"623":{"body":464,"breadcrumbs":4,"title":1},"624":{"body":4,"breadcrumbs":4,"title":1},"625":{"body":31,"breadcrumbs":4,"title":1},"626":{"body":71,"breadcrumbs":4,"title":1},"627":{"body":85,"breadcrumbs":4,"title":1},"628":{"body":25,"breadcrumbs":4,"title":1},"629":{"body":49,"breadcrumbs":5,"title":2},"63":{"body":8,"breadcrumbs":7,"title":2},"630":{"body":4,"breadcrumbs":4,"title":1},"631":{"body":25,"breadcrumbs":4,"title":1},"632":{"body":6,"breadcrumbs":4,"title":1},"633":{"body":108,"breadcrumbs":5,"title":2},"634":{"body":113,"breadcrumbs":5,"title":2},"635":{"body":17,"breadcrumbs":5,"title":2},"636":{"body":34,"breadcrumbs":4,"title":1},"637":{"body":4,"breadcrumbs":4,"title":1},"638":{"body":34,"breadcrumbs":4,"title":1},"639":{"body":19,"breadcrumbs":4,"title":1},"64":{"body":17,"breadcrumbs":6,"title":1},"640":{"body":128,"breadcrumbs":4,"title":1},"641":{"body":34,"breadcrumbs":4,"title":1},"642":{"body":4,"breadcrumbs":4,"title":1},"643":{"body":110,"breadcrumbs":4,"title":1},"644":{"body":57,"breadcrumbs":4,"title":1},"645":{"body":53,"breadcrumbs":5,"title":2},"646":{"body":4,"breadcrumbs":4,"title":1},"647":{"body":19,"breadcrumbs":4,"title":1},"648":{"body":111,"breadcrumbs":4,"title":1},"649":{"body":40,"breadcrumbs":4,"title":1},"65":{"body":133,"breadcrumbs":6,"title":1},"650":{"body":83,"breadcrumbs":4,"title":1},"651":{"body":209,"breadcrumbs":4,"title":1},"652":{"body":1,"breadcrumbs":5,"title":2},"653":{"body":29,"breadcrumbs":4,"title":1},"654":{"body":39,"breadcrumbs":5,"title":2},"655":{"body":28,"breadcrumbs":5,"title":2},"656":{"body":21,"breadcrumbs":5,"title":2},"657":{"body":336,"breadcrumbs":5,"title":2},"658":{"body":25,"breadcrumbs":4,"title":1},"659":{"body":0,"breadcrumbs":5,"title":2},"66":{"body":81,"breadcrumbs":7,"title":2},"660":{"body":33,"breadcrumbs":7,"title":4},"661":{"body":31,"breadcrumbs":4,"title":1},"662":{"body":106,"breadcrumbs":5,"title":2},"663":{"body":78,"breadcrumbs":6,"title":3},"664":{"body":326,"breadcrumbs":4,"title":1},"665":{"body":26,"breadcrumbs":5,"title":2},"666":{"body":0,"breadcrumbs":5,"title":2},"667":{"body":113,"breadcrumbs":8,"title":5},"668":{"body":38,"breadcrumbs":5,"title":2},"669":{"body":58,"breadcrumbs":7,"title":2},"67":{"body":60,"breadcrumbs":8,"title":3},"670":{"body":1,"breadcrumbs":7,"title":2},"671":{"body":21,"breadcrumbs":6,"title":2},"672":{"body":36,"breadcrumbs":6,"title":2},"673":{"body":1,"breadcrumbs":6,"title":2},"674":{"body":102,"breadcrumbs":6,"title":3},"675":{"body":27,"breadcrumbs":5,"title":2},"676":{"body":36,"breadcrumbs":7,"title":4},"677":{"body":71,"breadcrumbs":6,"title":3},"678":{"body":1,"breadcrumbs":5,"title":2},"679":{"body":21,"breadcrumbs":6,"title":2},"68":{"body":54,"breadcrumbs":8,"title":3},"680":{"body":29,"breadcrumbs":5,"title":1},"681":{"body":0,"breadcrumbs":6,"title":2},"682":{"body":98,"breadcrumbs":5,"title":1},"683":{"body":54,"breadcrumbs":5,"title":1},"684":{"body":54,"breadcrumbs":5,"title":1},"685":{"body":83,"breadcrumbs":5,"title":1},"686":{"body":60,"breadcrumbs":5,"title":1},"687":{"body":0,"breadcrumbs":6,"title":2},"688":{"body":94,"breadcrumbs":7,"title":3},"689":{"body":156,"breadcrumbs":6,"title":2},"69":{"body":97,"breadcrumbs":8,"title":3},"690":{"body":58,"breadcrumbs":5,"title":2},"691":{"body":40,"breadcrumbs":5,"title":2},"692":{"body":53,"breadcrumbs":7,"title":4},"693":{"body":33,"breadcrumbs":6,"title":3},"694":{"body":8,"breadcrumbs":4,"title":1},"695":{"body":0,"breadcrumbs":4,"title":1},"696":{"body":105,"breadcrumbs":4,"title":1},"697":{"body":0,"breadcrumbs":4,"title":1},"698":{"body":136,"breadcrumbs":4,"title":1},"699":{"body":19,"breadcrumbs":4,"title":1},"7":{"body":47,"breadcrumbs":3,"title":2},"70":{"body":0,"breadcrumbs":7,"title":2},"700":{"body":0,"breadcrumbs":4,"title":1},"701":{"body":271,"breadcrumbs":5,"title":2},"702":{"body":0,"breadcrumbs":5,"title":2},"703":{"body":28,"breadcrumbs":5,"title":2},"704":{"body":76,"breadcrumbs":6,"title":2},"705":{"body":105,"breadcrumbs":6,"title":2},"706":{"body":70,"breadcrumbs":8,"title":4},"707":{"body":0,"breadcrumbs":6,"title":2},"708":{"body":43,"breadcrumbs":7,"title":3},"709":{"body":79,"breadcrumbs":7,"title":3},"71":{"body":79,"breadcrumbs":9,"title":4},"710":{"body":10,"breadcrumbs":5,"title":1},"711":{"body":10,"breadcrumbs":5,"title":1},"712":{"body":35,"breadcrumbs":5,"title":1},"713":{"body":106,"breadcrumbs":5,"title":1},"714":{"body":92,"breadcrumbs":6,"title":2},"715":{"body":0,"breadcrumbs":5,"title":1},"716":{"body":22,"breadcrumbs":7,"title":3},"717":{"body":98,"breadcrumbs":6,"title":2},"718":{"body":0,"breadcrumbs":6,"title":2},"719":{"body":92,"breadcrumbs":8,"title":4},"72":{"body":25,"breadcrumbs":11,"title":6},"720":{"body":30,"breadcrumbs":7,"title":3},"721":{"body":50,"breadcrumbs":7,"title":3},"722":{"body":22,"breadcrumbs":7,"title":3},"723":{"body":31,"breadcrumbs":7,"title":3},"724":{"body":15,"breadcrumbs":5,"title":2},"725":{"body":43,"breadcrumbs":4,"title":1},"726":{"body":147,"breadcrumbs":7,"title":4},"727":{"body":58,"breadcrumbs":5,"title":2},"728":{"body":27,"breadcrumbs":5,"title":2},"729":{"body":67,"breadcrumbs":5,"title":2},"73":{"body":63,"breadcrumbs":10,"title":5},"730":{"body":49,"breadcrumbs":4,"title":1},"731":{"body":161,"breadcrumbs":2,"title":1},"732":{"body":0,"breadcrumbs":3,"title":2},"733":{"body":9,"breadcrumbs":4,"title":3},"734":{"body":12,"breadcrumbs":4,"title":3},"735":{"body":62,"breadcrumbs":2,"title":1},"736":{"body":12,"breadcrumbs":2,"title":1},"737":{"body":34,"breadcrumbs":4,"title":3},"738":{"body":38,"breadcrumbs":4,"title":3},"739":{"body":13,"breadcrumbs":4,"title":3},"74":{"body":17,"breadcrumbs":11,"title":4},"740":{"body":27,"breadcrumbs":4,"title":3},"741":{"body":27,"breadcrumbs":4,"title":3},"742":{"body":45,"breadcrumbs":2,"title":1},"743":{"body":19,"breadcrumbs":3,"title":2},"744":{"body":34,"breadcrumbs":4,"title":3},"745":{"body":57,"breadcrumbs":4,"title":3},"746":{"body":33,"breadcrumbs":2,"title":1},"747":{"body":31,"breadcrumbs":2,"title":1},"748":{"body":50,"breadcrumbs":3,"title":2},"749":{"body":36,"breadcrumbs":3,"title":2},"75":{"body":122,"breadcrumbs":8,"title":1},"750":{"body":9,"breadcrumbs":3,"title":2},"751":{"body":80,"breadcrumbs":2,"title":1},"752":{"body":34,"breadcrumbs":3,"title":2},"753":{"body":41,"breadcrumbs":5,"title":4},"754":{"body":21,"breadcrumbs":4,"title":3},"755":{"body":20,"breadcrumbs":3,"title":2},"756":{"body":9,"breadcrumbs":3,"title":2},"757":{"body":15,"breadcrumbs":2,"title":1},"758":{"body":21,"breadcrumbs":4,"title":3},"759":{"body":46,"breadcrumbs":3,"title":2},"76":{"body":41,"breadcrumbs":9,"title":2},"760":{"body":53,"breadcrumbs":2,"title":1},"761":{"body":10,"breadcrumbs":2,"title":1},"762":{"body":30,"breadcrumbs":3,"title":2},"763":{"body":0,"breadcrumbs":3,"title":2},"764":{"body":48,"breadcrumbs":3,"title":2},"765":{"body":36,"breadcrumbs":4,"title":3},"766":{"body":54,"breadcrumbs":3,"title":2},"767":{"body":77,"breadcrumbs":2,"title":1},"768":{"body":22,"breadcrumbs":3,"title":2},"769":{"body":40,"breadcrumbs":2,"title":1},"77":{"body":18,"breadcrumbs":9,"title":2},"770":{"body":50,"breadcrumbs":3,"title":2},"771":{"body":105,"breadcrumbs":4,"title":3},"772":{"body":97,"breadcrumbs":3,"title":2},"773":{"body":0,"breadcrumbs":5,"title":4},"774":{"body":36,"breadcrumbs":2,"title":1},"775":{"body":20,"breadcrumbs":4,"title":3},"776":{"body":38,"breadcrumbs":4,"title":3},"777":{"body":29,"breadcrumbs":3,"title":2},"778":{"body":45,"breadcrumbs":3,"title":2},"779":{"body":121,"breadcrumbs":4,"title":3},"78":{"body":294,"breadcrumbs":10,"title":3},"780":{"body":21,"breadcrumbs":4,"title":3},"781":{"body":18,"breadcrumbs":4,"title":3},"782":{"body":10,"breadcrumbs":4,"title":3},"783":{"body":25,"breadcrumbs":4,"title":3},"784":{"body":10,"breadcrumbs":4,"title":3},"785":{"body":49,"breadcrumbs":4,"title":3},"786":{"body":21,"breadcrumbs":4,"title":3},"787":{"body":0,"breadcrumbs":4,"title":3},"788":{"body":17,"breadcrumbs":3,"title":2},"789":{"body":91,"breadcrumbs":3,"title":2},"79":{"body":79,"breadcrumbs":11,"title":4},"790":{"body":26,"breadcrumbs":3,"title":2},"791":{"body":22,"breadcrumbs":5,"title":4},"792":{"body":14,"breadcrumbs":4,"title":3},"793":{"body":7,"breadcrumbs":5,"title":4},"794":{"body":46,"breadcrumbs":2,"title":1},"795":{"body":14,"breadcrumbs":3,"title":2},"796":{"body":32,"breadcrumbs":3,"title":2},"797":{"body":36,"breadcrumbs":3,"title":2},"798":{"body":21,"breadcrumbs":3,"title":2},"799":{"body":0,"breadcrumbs":4,"title":3},"8":{"body":51,"breadcrumbs":3,"title":2},"80":{"body":79,"breadcrumbs":10,"title":3},"800":{"body":71,"breadcrumbs":3,"title":2},"81":{"body":23,"breadcrumbs":10,"title":5},"82":{"body":74,"breadcrumbs":6,"title":1},"83":{"body":36,"breadcrumbs":9,"title":4},"84":{"body":112,"breadcrumbs":7,"title":2},"85":{"body":128,"breadcrumbs":9,"title":4},"86":{"body":153,"breadcrumbs":10,"title":5},"87":{"body":17,"breadcrumbs":6,"title":1},"88":{"body":0,"breadcrumbs":7,"title":2},"89":{"body":36,"breadcrumbs":7,"title":2},"9":{"body":27,"breadcrumbs":3,"title":2},"90":{"body":81,"breadcrumbs":9,"title":3},"91":{"body":29,"breadcrumbs":8,"title":2},"92":{"body":34,"breadcrumbs":9,"title":3},"93":{"body":54,"breadcrumbs":9,"title":3},"94":{"body":16,"breadcrumbs":7,"title":1},"95":{"body":56,"breadcrumbs":8,"title":2},"96":{"body":22,"breadcrumbs":11,"title":5},"97":{"body":19,"breadcrumbs":11,"title":5},"98":{"body":419,"breadcrumbs":12,"title":6},"99":{"body":0,"breadcrumbs":8,"title":2}},"docs":{"0":{"body":"Table of Contents About Optimism About the OP Stack Site Navigation","breadcrumbs":"Introduction » OP Stack Specification","id":"0","title":"OP Stack Specification"},"1":{"body":"Optimism is a project dedicated to scaling Ethereum's technology and expanding its ability to coordinate people from across the world to build effective decentralized economies and governance systems. The Optimism Collective builds open-source software that powers scalable blockchains and aims to address key governance and economic challenges in the wider Ethereum ecosystem. Optimism operates on the principle of impact=profit , the idea that individuals who positively impact the Collective should be proportionally rewarded with profit. Change the incentives and you change the world.","breadcrumbs":"Introduction » About Optimism","id":"1","title":"About Optimism"},"10":{"body":"We strive to preserve three critical properties: liveness, validity, and availability. A protocol that can maintain these properties can, effectively, scale Ethereum without sacrificing security.","breadcrumbs":"Background » Protocol Guarantees","id":"10","title":"Protocol Guarantees"},"100":{"body":"This updates which L2 blocks the engine considers to be canonical (forkchoiceState argument), and optionally initiates block production (payloadAttributes argument). Within the rollup, the types of forkchoice updates translate as: headBlockHash: block hash of the head of the canonical chain. Labeled \"unsafe\" in user JSON-RPC. Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts. safeBlockHash: block hash of the canonical chain, derived from L1 data, unlikely to reorg. finalizedBlockHash: irreversible block hash, matches lower boundary of the dispute period. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV2 : the extended PayloadAttributesV2 Extended PayloadAttributesV2 PayloadAttributesV2 is extended to: PayloadAttributesV2: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The type notation used here refers to the HEX value encoding used by the Ethereum JSON-RPC API specification , as this structure will need to be sent over JSON-RPC. array refers to a JSON array. Each item of the transactions array is a byte list encoding a transaction: TransactionType || TransactionPayload or LegacyTransaction, as defined in EIP-2718 . This is equivalent to the transactions field in ExecutionPayloadV2 The transactions field is optional: If empty or missing: no changes to engine behavior. The sequencers will (if enabled) build a block by consuming transactions from the transaction pool. If present and non-empty: the payload MUST be produced starting with this exact list of transactions. The rollup driver determines the transaction list based on deterministic L1 inputs. The noTxPool is optional as well, and extends the transactions meaning: If false, the execution engine is free to pack additional transactions from external sources like the tx pool into the payload, after any of the transactions. This is the default behavior a L1 node implements. If true, the execution engine must not change anything about the given list of transactions. If the transactions field is present, the engine must execute the transactions in order and return STATUS_INVALID if there is an error processing the transactions. It must return STATUS_VALID if all of the transactions could be executed without error. Note : The state transition rules have been modified such that deposits will never fail so if engine_forkchoiceUpdatedV2 returns STATUS_INVALID it is because a batched transaction is invalid. The gasLimit is optional w.r.t. compatibility with L1, but required when used as rollup. This field overrides the gas limit used during block-building. If not specified as rollup, a STATUS_INVALID is returned.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV2","id":"100","title":"engine_forkchoiceUpdatedV2"},"101":{"body":"See engine_forkchoiceUpdatedV2 for a description of the forkchoice updated method. engine_forkchoiceUpdatedV3 must only be called with Ecotone payload. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV3 : the extended PayloadAttributesV3 Extended PayloadAttributesV3 PayloadAttributesV3 is extended to: PayloadAttributesV3: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 parentBeaconBlockRoot: DATA (32 bytes) transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The requirements of this object are the same as extended PayloadAttributesV2 with the addition of parentBeaconBlockRoot which is the parent beacon block root from the L1 origin block of the L2 block. Starting at Ecotone, the parentBeaconBlockRoot must be set to the L1 origin parentBeaconBlockRoot, or a zero bytes32 if the Dencun functionality with parentBeaconBlockRoot is not active on L1.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV3","id":"101","title":"engine_forkchoiceUpdatedV3"},"102":{"body":"No modifications to engine_newPayloadV2 . Applies a L2 block to the engine state.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV2","id":"102","title":"engine_newPayloadV2"},"103":{"body":"engine_newPayloadV3 applies an Ecotone L2 block to the engine state. There are no modifications to this API. engine_newPayloadV3 must only be called with Ecotone payload. The additional parameters should be set as follows: expectedBlobVersionedHashes MUST be an empty array. parentBeaconBlockRoot MUST be the parent beacon block root from the L1 origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV3","id":"103","title":"engine_newPayloadV3"},"104":{"body":"No modifications to engine_getPayloadV2 . Retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV2 when called with payloadAttributes.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV2","id":"104","title":"engine_getPayloadV2"},"105":{"body":"engine_getPayloadV3 retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV3 when called with payloadAttributes. engine_getPayloadV3 must only be called with Ecotone payload. Extended Response The response is extended to: { executionPayload: ExecutionPayload blockValue: QUANTITY blobsBundle: BlobsBundle shouldOverrideBuilder: BOOLEAN parentBeaconBlockRoot: DATA (32 bytes)\n} In Ecotone it MUST be set to the parentBeaconBlockRoot from the L1 Origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV3","id":"105","title":"engine_getPayloadV3"},"106":{"body":"Optional extension to the Engine API. Signals superchain information to the Engine: V1 signals which protocol version is recommended and required. Types: SuperchainSignal: { recommended: ProtocolVersion; required: ProtocolVersion;\n} ProtocolVersion: encoded for RPC as defined in Protocol Version format specification . Parameters: signal: SuperchainSignal, the signaled superchain information. Returns: ProtocolVersion: the latest supported OP-Stack protocol version of the execution engine. The execution engine SHOULD warn the user when the recommended version is newer than the current version supported by the execution engine. The execution engine SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the execution engine operator.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_signalSuperchainV1","id":"106","title":"engine_signalSuperchainV1"},"107":{"body":"The execution engine can acquire all data through the rollup node, as derived from L1: P2P networking is strictly optional. However, to not bottleneck on L1 data retrieval speed, the P2P network functionality SHOULD be enabled, serving: Peer discovery ( Disc v5 ) eth/66 : Transaction pool (consumed by sequencer nodes) State sync (happy-path for fast trustless db replication) Historical block header and body retrieval New blocks are acquired through the consensus layer instead (rollup node) No modifications to L1 network functionality are required, except configuration: networkID : Distinguishes the L2 network from L1 and testnets. Equal to the chainID of the rollup network. Activate Merge fork: Enables Engine API and disables propagation of blocks, as block headers cannot be authenticated without consensus layer. Bootnode list: DiscV5 is a shared network, bootstrap is faster through connecting with L2 nodes first.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Networking","id":"107","title":"Networking"},"108":{"body":"The execution engine can operate sync in different ways: Happy-path: rollup node informs engine of the desired chain head as determined by L1, completes through engine P2P. Worst-case: rollup node detects stalled engine, completes sync purely from L1 data, no peers required. The happy-path is more suitable to bring new nodes online quickly, as the engine implementation can sync state faster through methods like snap-sync .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Sync","id":"108","title":"Sync"},"109":{"body":"The rollup node informs the engine of the L2 chain head, unconditionally (part of regular node operation): Bedrock / Canyon / Delta Payloads engine_newPayloadV2 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV2 is called with the current unsafe/safe/finalized L2 block hashes. Ecotone Payloads engine_newPayloadV3 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV3 is called with the current unsafe/safe/finalized L2 block hashes. The engine requests headers from peers, in reverse till the parent hash matches the local chain The engine catches up: a) A form of state sync is activated towards the finalized or head block hash b) A form of block sync pulls block bodies and processes towards head block hash The exact P2P based sync is out of scope for the L2 specification: the operation within the engine is the exact same as with L1 (although with an EVM that supports deposits).","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Happy-path sync","id":"109","title":"Happy-path sync"},"11":{"body":"Liveness is defined as the ability for any party to be able to extend the rollup chain by including a transaction within a bounded amount of time. It should not be possible for an actor to block the inclusion of any given transaction for more than this bounded time period. This bounded time period should also be acceptable such that inclusion is not just theoretically possible but practically useful.","breadcrumbs":"Background » Liveness","id":"11","title":"Liveness"},"110":{"body":"Engine is out of sync, not peered and/or stalled due other reasons. The rollup node maintains latest head from engine (poll eth_getBlockByNumber and/or maintain a header subscription) The rollup node activates sync if the engine is out of sync but not syncing through P2P (eth_syncing) The rollup node inserts blocks, derived from L1, one by one, potentially adapting to L1 reorg(s), as outlined in the rollup node spec .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Worst-case sync","id":"110","title":"Worst-case sync"},"111":{"body":"EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction, plus a list of \"blobs\": \"Binary Large Object\", i.e. a dedicated data type for serving Data-Availability as base-layer. With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception: as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type. EIP-4844 is disabled as following: Transaction network-layer announcements, announcing blob-type transactions, are ignored. Transactions of the blob-type, through the RPC or otherwise, are not allowed into the transaction pool. Block-building code does not select EIP-4844 transactions. An L2 block state-transition with EIP-4844 transactions is invalid. The BLOBBASEFEE opcode is present but its semantics are altered because there are no blobs processed by L2. The opcode will always push a value of 1 onto the stack.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: disable Blob-transactions","id":"111","title":"Ecotone: disable Blob-transactions"},"112":{"body":"EIP-4788 introduces a \"beacon block root\" into the execution-layer block-header and EVM. This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block. With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO of L1. And thus with EIP-4788 the L1 beacon block root is made available. For the Ecotone upgrade, this entails that: The parent_beacon_block_root of the L1 origin is now embedded in the L2 block header. The \"Beacon roots contract\" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis. The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: Beacon Block Root","id":"112","title":"Ecotone: Beacon Block Root"},"113":{"body":"The Ethereum Node Record (ENR) for an Optimism execution node must contain an opel key-value pair where the key is opel and the value is a EIP-2124 fork id. The EL uses a different key from the CL in order to stop EL and CL nodes from connecting to each other.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » P2P Modifications","id":"113","title":"P2P Modifications"},"114":{"body":"Table of Contents Overview Driver Derivation L2 Output RPC method Structures BlockID L1BlockRef L2BlockRef SyncStatus Output Method API Protocol Version tracking","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node Specification","id":"114","title":"Rollup Node Specification"},"115":{"body":"The rollup node is the component responsible for deriving the L2 chain from L1 blocks (and their associated receipts ). The part of the rollup node that derives the L2 chain is called the rollup driver . This document is currently only concerned with the specification of the rollup driver.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Overview","id":"115","title":"Overview"},"116":{"body":"The task of the driver in the rollup node is to manage the derivation process: Keep track of L1 head block Keep track of the L2 chain sync progress Iterate over the derivation steps as new inputs become available","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Driver","id":"116","title":"Driver"},"117":{"body":"This process happens in three steps: Select inputs from the L1 chain, on top of the last L2 block: a list of blocks, with transactions and associated data and receipts. Read L1 information, deposits, and sequencing batches in order to generate payload attributes (essentially a block without output properties ). Pass the payload attributes to the execution engine , so that the L2 block (including output block properties ) may be computed. While this process is conceptually a pure function from the L1 chain to the L2 chain, it is in practice incremental. The L2 chain is extended whenever new L1 blocks are added to the L1 chain. Similarly, the L2 chain re-organizes whenever the L1 chain re-organizes . For a complete specification of the L2 block derivation, refer to the L2 block derivation document .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation","id":"117","title":"Derivation"},"118":{"body":"The Rollup node has its own RPC method, optimism_outputAtBlock which returns a 32 byte hash corresponding to the L2 output root .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » L2 Output RPC method","id":"118","title":"L2 Output RPC method"},"119":{"body":"These define the types used by rollup node API methods. The types defined here are extended from the engine API specs . BlockID hash: DATA, 32 Bytes number: QUANTITY, 64 Bits L1BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits L2BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits l1origin: BlockID sequenceNumber: QUANTITY, 64 Bits - distance to first block of epoch SyncStatus Represents a snapshot of the rollup driver. current_l1: Object - instance of L1BlockRef . current_l1_finalized: Object - instance of L1BlockRef . head_l1: Object - instance of L1BlockRef . safe_l1: Object - instance of L1BlockRef . finalized_l1: Object - instance of L1BlockRef . unsafe_l2: Object - instance of L2BlockRef . safe_l2: Object - instance of L2BlockRef . finalized_l2: Object - instance of L2BlockRef . pending_safe_l2: Object - instance of L2BlockRef . queued_unsafe_l2: Object - instance of L2BlockRef .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Structures","id":"119","title":"Structures"},"12":{"body":"Validity is defined as the ability for any party to execute the rollup state transition function, subject to certain lower bound expectations for available computing and bandwidth resources. Validity is also extended to refer to the ability for a smart contract on Ethereum to be able to validate this state transition function economically.","breadcrumbs":"Background » Validity","id":"12","title":"Validity"},"120":{"body":"The input and return types here are as defined by the engine API specs . method: optimism_outputAtBlock params: blockNumber: QUANTITY, 64 bits - L2 integer block number. returns: version: DATA, 32 Bytes - the output root version number, beginning with 0. outputRoot: DATA, 32 Bytes - the output root. blockRef: Object - instance of L2BlockRef . withdrawalStorageRoot: 32 bytes - storage root of the L2toL1MessagePasser contract. stateRoot: DATA: 32 bytes - the state root. syncStatus: Object - instance of SyncStatus .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Output Method API","id":"120","title":"Output Method API"},"121":{"body":"The rollup-node should monitor the recommended and required protocol version by monitoring the Protocol Version contract on L1, as specified in the Superchain Version Signaling specifications . This can be implemented through polling in the Driver loop. After polling the Protocol Version, the rollup node SHOULD communicate it with the execution-engine through an engine_signalSuperchainV1 call. The rollup node SHOULD warn the user when the recommended version is newer than the current version supported by the rollup node. The rollup node SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the rollup node operator.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Protocol Version tracking","id":"121","title":"Protocol Version tracking"},"122":{"body":"Table of Contents Overview P2P configuration Identification Discv5 Consensus Layer Structure LibP2P Transport Dialing NAT Peer management Transport security Protocol negotiation Identify Ping Multiplexing GossipSub Content-based message identification Message compression and limits Message ID computation Heartbeat and parameters Topic configuration Topic validation Gossip Topics blocksv1 blocksv2 blocksv3 Block encoding Block signatures Block validation Block processing Block topic scoring parameters Req-Resp payload_by_number","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Rollup-node P2P interface","id":"122","title":"Rollup-node P2P interface"},"123":{"body":"The rollup node has an optional peer-to-peer (P2P) network service to improve the latency between the view of sequencers and the rest of the network by bypassing the L1 in the happy case, without relying on a single centralized endpoint. This also enables faster historical sync to be bootstrapped by providing block headers to sync towards, and only having to compare the L2 chain inputs to the L1 data as compared to processing everything one block at a time. The rollup node will always prioritize L1 and reorganize to match the canonical chain. The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the \"unsafe\" chain, to improve the happy case performance. This also means that P2P behavior is a soft-rule: nodes keep each other in check with scoring and eventual banning of malicious peers by identity or IP. Any behavior on the P2P layer does not affect the rollup security, at worst nodes rely on higher-latency data from L1 to serve. In summary, the P2P stack looks like: Discovery to find peers: Discv5 Connections, peering, transport security, multiplexing, gossip: LibP2P Application-layer publishing and validation of gossiped messages like L2 blocks. This document only specifies the composition and configuration of these network libraries. These components have their own standards, implementations in Go/Rust/Java/Nim/JS/more, and are adopted by several other blockchains, most notably the L1 consensus layer (Eth2) .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Overview","id":"123","title":"Overview"},"124":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » P2P configuration","id":"124","title":"P2P configuration"},"125":{"body":"Nodes have a separate network- and consensus-identity. The network identity is a secp256k1 key, used for both discovery and active LibP2P connections. Common representations of network identity: PeerID: a LibP2P specific ID derived from the pubkey (through protobuf encoding, typing and hashing) NodeID: a Discv5 specific ID derived from the pubkey (through hashing, used in the DHT) Multi-address: an unsigned address, containing: IP, TCP port, PeerID ENR: a signed record used for discovery, containing: IP, TCP port, UDP port, signature (pubkey can be derived) and L2 network identification. Generally encoded in base64.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Identification","id":"125","title":"Identification"},"126":{"body":"Consensus Layer Structure The Ethereum Node Record (ENR) for an Optimism rollup node must contain the following values, identified by unique keys: An IPv4 address (ip field) and/or IPv6 address (ip6 field). A TCP port (tcp field) representing the local libp2p listening port. A UDP port (udp field) representing the local discv5 listening port. An OpStack (opstack field) L2 network identifier The opstack value is encoded as a single RLP bytes value, the concatenation of: chain ID (unsigned varint) fork ID (unsigned varint) Note that DiscV5 is a shared DHT (Distributed Hash Table): the L1 consensus and execution nodes, as well as testnet nodes, and even external IOT nodes, all communicate records in this large common DHT. This makes it more difficult to censor the discovery of node records. The discovery process in Optimism is a pipeline of node records: Fill the table with FINDNODES if necessary (Performed by Discv5 library) Pull additional records with searches to random Node IDs if necessary (e.g. iterate RandomNodes() in Go implementation) Pull records from the DiscV5 module when looking for peers Check if the record contains the opstack entry, verify it matches the chain ID and current or future fork number If not already connected, and not recently disconnected or put on deny-list, attempt to dial.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Discv5","id":"126","title":"Discv5"},"127":{"body":"Transport TCP transport. Additional transports are supported by LibP2P, but not required. Dialing Nodes should be publicly dialable, not rely on relay extensions, and able to dial both IPv4 and IPv6. NAT The listening endpoint must be publicly facing, but may be configured behind a NAT. LibP2P will use PMP / UPNP based techniques to track the external IP of the node. It is recommended to disable the above if the external IP is static and configured manually. Peer management The default is to maintain a peer count with a tide-system based on active peer count: At \"low tide\" the node starts to actively search for additional peer connections. At \"high tide\" the node starts to prune active connections, except those that are marked as trusted or have a grace period. Peers will have a grace period for a configurable amount of time after joining. In an emergency, when memory runs low, the node should start pruning more aggressively. Peer records can be persisted to disk to quickly reconnect with known peers after restarting the rollup node. The discovery process feeds the peerstore with peer records to connect to, tagged with a time-to-live (TTL). The current P2P processes do not require selective topic-specific peer connections, other than filtering for the basic network participation requirement. Peers may be banned if their performance score is too low, or if an objectively malicious action was detected. Banned peers will be persisted to the same data-store as the peerstore records. TODO: the connection gater does currently not gate by IP address on the dial Accept-callback. Transport security Libp2p-noise , XX handshake, with the secp256k1 P2P identity, as popularized in Eth2. The TLS option is available as well, but noise should be prioritized in negotiation. Protocol negotiation Multistream-select 1.0 (/multistream/1.0.0) is an interactive protocol used to negotiate sub-protocols supported in LibP2P peers. Multistream-select 2.0 may be used in the future. Identify LibP2P offers a minimal identification module to share client version and programming language. This is optional and can be disabled for enhanced privacy. It also includes the same protocol negotiation information, which can speed up initial connections. Ping LibP2P includes a simple ping protocol to track latency between connections. This should be enabled to help provide insight into the network health. Multiplexing For async communication over different channels over the same connection, multiplexing is used. mplex (/mplex/6.7.0) is required, and yamux (/yamux/1.0.0) is recommended but optional GossipSub GossipSub 1.1 (/meshsub/1.1.0, i.e. with peer-scoring extension) is a pubsub protocol for mesh-networks, deployed on L1 consensus (Eth2) and other protocols such as Filecoin, offering lots of customization options. Content-based message identification Messages are deduplicated, and filtered through application-layer signature verification. Thus origin-stamping is disabled and published messages must only contain application data, enforced through a StrictNoSign Signature Policy This provides greater privacy, and allows sequencers (consensus identity) to maintain multiple network identities for redundancy. Message compression and limits The application contents are compressed with snappy single-block-compression (as opposed to frame-compression), and constrained to 10 MiB. Message ID computation Same as L1 , with recognition of compression: If message.data has a valid snappy decompression, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_VALID_SNAPPY with the snappy decompressed message data, i.e. SHA256(MESSAGE_DOMAIN_VALID_SNAPPY + snappy_decompress(message.data))[:20]. Otherwise, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_INVALID_SNAPPY with the raw message data, i.e. SHA256(MESSAGE_DOMAIN_INVALID_SNAPPY + message.data)[:20]. Heartbeat and parameters GossipSub parameters : D (topic stable mesh target count): 8 D_low (topic stable mesh low watermark): 6 D_high (topic stable mesh high watermark): 12 D_lazy (gossip target): 6 heartbeat_interval (interval of heartbeat, in seconds): 0.5 fanout_ttl (ttl for fanout maps for topics we are not subscribed to but have published to, in seconds): 24 mcache_len (number of windows to retain full messages in cache for IWANT responses): 12 mcache_gossip (number of windows to gossip about): 3 seen_ttl (number of heartbeat intervals to retain message IDs): 130 (= 65 seconds) Notable differences from L1 consensus (Eth2): seen_ttl does not need to cover a full L1 epoch (6.4 minutes), but rather just a small window covering latest blocks fanout_ttl: adjusted to lower than seen_ttl mcache_len: a larger number of heartbeats can be retained since the gossip is much less noisy. heartbeat_interval: faster interval to reduce latency, bandwidth should still be reasonable since there are far fewer messages to gossip about each interval than on L1 which uses an interval of 0.7 seconds. Topic configuration Topics have string identifiers and are communicated with messages and subscriptions. /optimism/chain_id/hardfork_version/Name chain_id: replace with decimal representation of chain ID hardfork_version: replace with decimal representation of hardfork, starting at 0 Name: topic application-name Note that the topic encoding depends on the topic, unlike L1, since there are less topics, and all are snappy-compressed. Topic validation To ensure only valid messages are relayed, and malicious peers get scored based on application behavior, an extended validator checks the message before it is relayed or processed. The extended validator emits one of the following validation signals: ACCEPT valid, relayed to other peers and passed to local topic subscriber IGNORE scored like inactivity, message is dropped and not processed REJECT score penalties, message is dropped","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » LibP2P","id":"127","title":"LibP2P"},"128":{"body":"There are three topics for distributing blocks to other nodes faster than proxying through L1 would. These are:","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Gossip Topics","id":"128","title":"Gossip Topics"},"129":{"body":"Pre-Canyon/Shanghai blocks are broadcast on /optimism//0/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv1","id":"129","title":"blocksv1"},"13":{"body":"Availability is defined as the ability for any party to retrieve the inputs that are necessary to execute the rollup state transition function correctly. Availability is essentially an element of validity and is required to be able to guarantee validity in general. Similar to validity, availability is subject to lower bound resource requirements.","breadcrumbs":"Background » Availability","id":"13","title":"Availability"},"130":{"body":"Canyon/Delta blocks are broadcast on /optimism//1/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv2","id":"130","title":"blocksv2"},"131":{"body":"Ecotone blocks are broadcast on /optimism//2/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv3","id":"131","title":"blocksv3"},"132":{"body":"A block is structured as the concatenation of: V1 and V2 topics signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. V3 topic signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) parentBeaconBlockRoot: L1 origin parent beacon block root, always 32 bytes payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. All topics use Snappy block-compression (i.e. no snappy frames): the above needs to be compressed after encoding, and decompressed before decoding.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block encoding","id":"132","title":"Block encoding"},"133":{"body":"The signature is a secp256k1 signature, and signs over a message: keccak256(domain ++ chain_id ++ payload_hash), where: domain is 32 bytes, reserved for message types and versioning info. All zero for this signature. chain_id is a big-endian encoded uint256. payload_hash is keccak256(payload), where payload is the payload in V1 and V2, and parentBeaconBlockRoot ++ payload in V3. The secp256k1 signature must have y_parity = 1 or 0, the chain_id is already signed over.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block signatures","id":"133","title":"Block signatures"},"134":{"body":"An extended-validator checks the incoming messages as follows, in order of operation: [REJECT] if the compression is not valid [REJECT] if the block encoding is not valid [REJECT] if the payload.timestamp is older than 60 seconds in the past (graceful boundary for worst-case propagation and clock skew) [REJECT] if the payload.timestamp is more than 5 seconds into the future [REJECT] if the block_hash in the payload is not valid [REJECT] if the block is on the V1 topic and has withdrawals [REJECT] if the block is on the V1 topic and has a withdrawals list [REJECT] if the block is on a topic >= V2 and does not have an empty withdrawals list [REJECT] if the block is on a topic <= V2 and has a blob gas-used value set [REJECT] if the block is on a topic <= V2 and has an excess blob gas value set [REJECT] if the block is on a topic >= V3 and has a blob gas-used value that is not zero [REJECT] if the block is on a topic >= V3 and has an excess blob gas value that is not zero [REJECT] if the block is on a topic <= V2 and the parent beacon block root is not nil [REJECT] if the block is on a topic >= V3 and the parent beacon block root is nil [REJECT] if more than 5 different blocks have been seen with the same block height [IGNORE] if the block has already been seen [REJECT] if the signature by the sequencer is not valid Mark the block as seen for the given block height The block is signed by the corresponding sequencer, to filter malicious messages. The sequencer model is singular but may change to multiple sequencers in the future. A default sequencer pubkey is distributed with rollup nodes and should be configurable. Note that blocks that a block may still be propagated even if the L1 already confirmed a different block. The local L1 view of the node may be wrong, and the time and signature validation will prevent spam. Hence, calling into the execution engine with a block lookup every propagation step is not worth the added delay. Block processing A node may apply the block to their local engine ahead of L1 availability, if it ensures that: The application of the block is reversible, in case of a conflict with delayed L1 information The subsequent forkchoice-update ensures this block is recognized as \"unsafe\" (see fork choice updated ) Block topic scoring parameters TODO: GossipSub per-topic scoring to fine-tune incentives for ideal propagation delay and bandwidth usage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block validation","id":"134","title":"Block validation"},"135":{"body":"The op-node implements a similar request-response encoding for its sync protocols as the L1 ethereum Beacon-Chain. See L1 P2P-interface req-resp specification and Altair P2P update . However, the protocol is simplified, to avoid several issues seen in L1: Error strings in responses, if there is any alternative response, should not need to be compressed or have an artificial global length limit. Payload lengths should be fixed-length: byte-by-byte uvarint reading from the underlying stream is undesired. are relaxed to encode a uint32, rather than a beacon-chain ForkDigest. Payload-encoding may change per hardfork, so is not part of the protocol-ID. Usage of response-chunks is specific to the req-resp method: most basic req-resp does not need chunked responses. Compression is encouraged to be part of the payload-encoding, specific to the req-resp method, where necessary: pings and such do not need streaming frame compression etc. And the protocol ID format follows the same scheme as L1, except the trailing encoding schema part, which is now message-specific: /ProtocolPrefix/MessageName/SchemaVersion/ The req-resp protocols served by the op-node all have /ProtocolPrefix set to /opstack/req. Individual methods may include the chain ID as part of the /MessageName segment, so it's immediately clear which chain the method applies to, if the communication is chain-specific. Other methods may include chain-information in the request and/or response data, such as the ForkDigest in L1 beacon chain req-resp protocols. Each segment starts with a /, and may contain multiple /, and the final protocol ID is suffixed with a /.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Req-Resp","id":"135","title":"Req-Resp"},"136":{"body":"This is an optional chain syncing method, to request/serve execution payloads by number. This serves as a method to fill gaps upon missed gossip, and sync short to medium ranges of unsafe L2 blocks. Protocol ID: /opstack/req/payload_by_number//0/ /MessageName is /block_by_number/ where is set to the op-node L2 chain ID. /SchemaVersion is /0 Request format: : a little-endian uint64 - the block number to request. Response format: = is a byte code describing the result. 0 on success, should follow. 1 if valid request, but unavailable payload. 2 if invalid request 3+ if other error The >= 128 range is reserved for future use. is a little-endian uint32, identifying the response type (fork-specific) is an encoded block, read till stream EOF. The input of should be limited, as well as any generated decompressed output, to avoid unexpected resource usage or zip-bomb type attacks. A 10 MB limit is recommended, to ensure all blocks may be synced. Implementations may opt for a different limit, since this sync method is optional. list: 0: SSZ-encoded ExecutionPayload, with Snappy framing compression, matching the ExecutionPayload SSZ definition of the L1 Merge, L2 Bedrock and L2 Regolith, L2 Canyon versions. 1: SSZ-encoded ExecutionPayloadEnvelope with Snappy framing compression, matching the ExecutionPayloadEnvelope SSZ definition of the L2 Ecotone version. The request is by block-number, enabling parallel fetching of a chain across many peers. A res = 0 response should be verified to: Have a block-number matching the requested block number. Have a consistent blockhash w.r.t. the other block contents. Build towards a known canonical block. This can be verified by checking if the parent-hash of a previous trusted canonical block matches that of the verified hash of the retrieved block. For unsafe blocks this may be relaxed to verification against the parent-hash of any previously trusted block: The gossip validation process limits the amount of blocks that may be trusted to sync towards. The unsafe blocks should be queued for processing, the latest received L2 unsafe blocks should always override any previous chain, until the final L2 chain can be reproduced from L1 data. A res > 0 response code should not be accepted. The result code is helpful for debugging, but the client should regard any error like any other unanswered request, as the responding peer cannot be trusted.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » payload_by_number","id":"136","title":"payload_by_number"},"137":{"body":"Table of Contents Overview Eager Block Derivation Protocol Parameters Batch Submission Sequencing & Batch Submission Overview Batch Submission Wire Format Batcher Transaction Format Frame Format Channel Format Batch Format Architecture L2 Chain Derivation Pipeline L1 Traversal L1 Retrieval Frame Queue Channel Bank Pruning Timeouts Reading Loading frames Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue Engine API usage Bedrock, Canyon, Delta: API Usage Ecotone: API Usage Forkchoice synchronization L1-consolidation: payload attributes matching L1-sync: payload attributes processing Processing unsafe payload attributes Resetting the Pipeline Finding the sync starting point Resetting derivation stages About reorgs Post-Merge Deriving Payload Attributes Deriving the Transaction List Network upgrade automation transactions Ecotone L1Block Deployment GasPriceOracle Deployment L1Block Proxy Update GasPriceOracle Proxy Update GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) Building Individual Payload Attributes","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Specification","id":"137","title":"L2 Chain Derivation Specification"},"138":{"body":"Note the following assumes a single sequencer and batcher. In the future, the design will be adapted to accommodate multiple such entities. L2 chain derivation — deriving L2 blocks from L1 data — is one of the main responsibilities of the rollup node , both in validator mode, and in sequencer mode (where derivation acts as a sanity check on sequencing, and enables detecting L1 chain re-organizations ). The L2 chain is derived from the L1 chain. In particular, each L1 block following L2 chain inception is mapped to a sequencing epoch comprising at least one L2 block. Each L2 block belongs to exactly one epoch, and we call the corresponding L1 block its L1 origin . The epoch's number equals that of its L1 origin block. To derive the L2 blocks of epoch number E, we need the following inputs: L1 blocks in the range [E, E + SWS), called the sequencing window of the epoch, and SWS the sequencing window size. (Note that sequencing windows overlap.) Batcher transactions from blocks in the sequencing window. These transactions allow us to reconstruct the epoch's sequencer batches , each of which will produce one L2 block. Note that: The L1 origin will never contain any data needed to construct sequencer batches since each batch must contain the L1 origin hash. An epoch may have no sequencer batches. Deposits made in the L1 origin (in the form of events emitted by the deposit contract ). L1 block attributes from the L1 origin (to derive the L1 attributes deposited transaction ). The state of the L2 chain after the last L2 block of the previous epoch, or the L2 genesis state if E is the first epoch. To derive the whole L2 chain from scratch, we start with the L2 genesis state and the L2 genesis block as the first L2 block. We then derive L2 blocks from each epoch in order, starting at the first L1 block following L2 chain inception . Refer to the Architecture section for more information on how we implement this in practice. The L2 chain may contain pre-Bedrock history, but the L2 genesis here refers to the Bedrock L2 genesis block. Each L2 block with origin l1_origin is subject to the following constraints (whose values are denominated in seconds): block.timestamp = prev_l2_timestamp + l2_block_time prev_l2_timestamp is the timestamp of the L2 block immediately preceding this one. If there is no preceding block, then this is the genesis block, and its timestamp is explicitly specified. l2_block_time is a configurable parameter of the time between L2 blocks (2s on Optimism). l1_origin.timestamp <= block.timestamp <= max_l2_timestamp, where max_l2_timestamp = max(l1_origin.timestamp + max_sequencer_drift, prev_l2_timestamp + l2_block_time) max_sequencer_drift is a configurable parameter that bounds how far the sequencer can get ahead of the L1. Finally, each epoch must have at least one L2 block. The first constraint means there must be an L2 block every l2_block_time seconds following L2 chain inception. The second constraint ensures that an L2 block timestamp never precedes its L1 origin timestamp, and is never more than max_sequencer_drift ahead of it, except only in the unusual case where it might prohibit an L2 block from being produced every l2_block_time seconds. (Such cases might arise for example under a proof-of-work L1 that sees a period of rapid L1 block production.) In either case, the sequencer enforces len(batch.transactions) == 0 while max_sequencer_drift is exceeded. See Batch Queue for more details. The final requirement that each epoch must have at least one L2 block ensures that all relevant information from the L1 (e.g. deposits) is represented in the L2, even if it has no sequencer batches. Post-merge, Ethereum has a fixed 12s block time , though some slots can be skipped. Under a 2s L2 block time, we thus expect each epoch to typically contain 12/2 = 6 L2 blocks. The sequencer will however produce bigger epochs in order to maintain liveness in case of either a skipped slot on the L1 or a temporary loss of connection to it. For the lost connection case, smaller epochs might be produced after the connection was restored to keep L2 timestamps from drifting further and further ahead.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Overview","id":"138","title":"Overview"},"139":{"body":"Deriving an L2 block requires that we have constructed its sequencer batch and derived all L2 blocks and state updates prior to it. This means we can typically derive the L2 blocks of an epoch eagerly without waiting on the full sequencing window. The full sequencing window is required before derivation only in the very worst case where some portion of the sequencer batch for the first block of the epoch appears in the very last L1 block of the window. Note that this only applies to block derivation. Sequencer batches can still be derived and tentatively queued without deriving blocks from them.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Eager Block Derivation","id":"139","title":"Eager Block Derivation"},"14":{"body":"Generally speaking, there are three primary actors that interact with an OP Stack chain: users, sequencers, and verifiers. graph TD EthereumL1(Ethereum L1) subgraph \"L2 Participants\" Users(Users) Sequencers(Sequencers) Verifiers(Verifiers) end Verifiers -.->|fetch transaction batches| EthereumL1 Verifiers -.->|fetch deposit data| EthereumL1 Verifiers -->|submit/validate/challenge output proposals| EthereumL1 Verifiers -.->|fetch realtime P2P updates| Sequencers Users -->|submit deposits/withdrawals| EthereumL1 Users -->|submit transactions| Sequencers Users -->|query data| Verifiers Sequencers -->|submit transaction batches| EthereumL1 Sequencers -.->|fetch deposit data| EthereumL1 classDef l1Contracts stroke:#bbf,stroke-width:2px; classDef l2Components stroke:#333,stroke-width:2px; classDef systemUser stroke:#f9a,stroke-width:2px; class EthereumL1 l1Contracts; class Users,Sequencers,Verifiers l2Components;","breadcrumbs":"Background » Network Participants","id":"14","title":"Network Participants"},"140":{"body":"The following table gives an overview of some protocol parameters, and how they are affected by protocol upgrades. Parameter Bedrock (default) value Latest (default) value Changes Notes max_sequencer_drift 600 1800 Fjord Changed from a chain parameter to a constant with Fjord. MAX_RLP_BYTES_PER_CHANNEL 10,000,000 100,000,000 Fjord Constant increased with Fjord. MAX_CHANNEL_BANK_SIZE 100,000,000 1,000,000,000 Fjord Constant increased with Fjord. MAX_SPAN_BATCH_ELEMENT_COUNT 10,000,000 10,000,000 Effectively introduced in Fjord Number of elements","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Protocol Parameters","id":"140","title":"Protocol Parameters"},"141":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission","id":"141","title":"Batch Submission"},"142":{"body":"The sequencer accepts L2 transactions from users. It is responsible for building blocks out of these. For each such block, it also creates a corresponding sequencer batch . It is also responsible for submitting each batch to a data availability provider (e.g. Ethereum calldata), which it does via its batcher component. The difference between an L2 block and a batch is subtle but important: the block includes an L2 state root, whereas the batch only commits to transactions at a given L2 timestamp (equivalently: L2 block number). A block also includes a reference to the previous block (*). (*) This matters in some edge case where a L1 reorg would occur and a batch would be reposted to the L1 chain but not the preceding batch, whereas the predecessor of an L2 block cannot possibly change. This means that even if the sequencer applies a state transition incorrectly, the transactions in the batch will still be considered part of the canonical L2 chain. Batches are still subject to validity checks (i.e. they have to be encoded correctly), and so are individual transactions within the batch (e.g. signatures have to be valid). Invalid batches and invalid individual transactions within an otherwise valid batch are discarded by correct nodes. If the sequencer applies a state transition incorrectly and posts an output root , then this output root will be incorrect. The incorrect output root will be challenged by a fault proof , then replaced by a correct output root for the existing sequencer batches. Refer to the Batch Submission specification for more information.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Sequencing & Batch Submission Overview","id":"142","title":"Sequencing & Batch Submission Overview"},"143":{"body":"Batch submission is closely tied to L2 chain derivation because the derivation process must decode the batches that have been encoded for the purpose of batch submission. The batcher submits batcher transactions to a data availability provider . These transactions contain one or multiple channel frames , which are chunks of data belonging to a channel . A channel is a sequence of sequencer batches (for any L2 blocks) compressed together. The reason to group multiple batches together is simply to obtain a better compression rate, hence reducing data availability costs. Channels might be too large to fit in a single batcher transaction , hence we need to split it into chunks known as channel frames . A single batcher transaction can also carry multiple frames (belonging to the same or to different channels). This design gives use the maximum flexibility in how we aggregate batches into channels, and split channels over batcher transactions. It notably allows us to maximize data utilization in a batcher transaction: for instance it allows us to pack the final (small) frame of one channel with one or more frames from the next channel. Also note that we use a streaming compression scheme, and we do not need to know how many batches a channel will end up containing when we start a channel, or even as we send the first frames in the channel. And by splitting channels across multiple data transactions, the L2 can have larger block data than the data-availability layer may support. All of this is illustrated in the following diagram. Explanations below. batch derivation chain diagram The first line represents L1 blocks with their numbers. The boxes under the L1 blocks represent batcher transactions included within the block. The squiggles under the L1 blocks represent deposits (more specifically, events emitted by the deposit contract ). Each colored chunk within the boxes represents a channel frame . So A and B are channels whereas A0, A1, B0, B1, B2 are frames. Notice that: multiple channels are interleaved frames do not need to be transmitted in order a single batcher transaction can carry frames from multiple channels In the next line, the rounded boxes represent individual sequencer batches that were extracted from the channels. The four blue/purple/pink were derived from channel A while the other were derived from channel B. These batches are here represented in the order they were decoded from batches (in this case B is decoded first). Note The caption here says \"Channel B was seen first and will be decoded into batches first\", but this is not a requirement. For instance, it would be equally acceptable for an implementation to peek into the channels and decode the one that contains the oldest batches first. The rest of the diagram is conceptually distinct from the first part and illustrates L2 chain derivation after the channels have been reordered. The first line shows batcher transactions. Note that in this case, there exists an ordering of the batches that makes all frames within the channels appear contiguously. This is not true in general. For instance, in the second transaction, the position of A1 and B0 could have been inverted for exactly the same result — no changes needed in the rest of the diagram. The second line shows the reconstructed channels in proper order. The third line shows the batches extracted from the channel. Because the channels are ordered and the batches within a channel are sequential, this means the batches are ordered too. The fourth line shows the L2 block derived from each batch. Note that we have a 1-1 batch to block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there are \"gaps\" in the batches posted on L1. The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while the second number (the \"sequence number\") denotes the position within the epoch. Finally, the sixth line shows user-deposited transactions derived from the deposit contract event mentioned earlier. Note the 101-0 L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if frame B2 indicates that it is the last frame within the channel and (2) no empty blocks must be inserted. The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4 blocks, because the last frame of channel A appears in block 102, but belong to epoch 99. As for the comment on \"security types\", it explains the classification of blocks as used on L1 and L2. Unsafe L2 blocks : Safe L2 blocks : Finalized L2 blocks: refer to block that have been derived from finalized L1 data. These security levels map to the headBlockHash, safeBlockHash and finalizedBlockHash values transmitted when interacting with the execution-engine API .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission Wire Format","id":"143","title":"Batch Submission Wire Format"},"144":{"body":"Batcher transactions are encoded as version_byte ++ rollup_payload (where ++ denotes concatenation). version_byte rollup_payload 0 frame ... (one or more frames, concatenated) 1 da_commitment (experimental, see alt-da ) Unknown versions make the batcher transaction invalid (it must be ignored by the rollup node). All frames in a batcher transaction must be parseable. If any one frame fails to parse, the all frames in the transaction are rejected. Batch transactions are authenticated by verifying that the to address of the transaction matches the batch inbox address, and the from address matches the batch-sender address in the system configuration at the time of the L1 block that the transaction data is read from.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batcher Transaction Format","id":"144","title":"Batcher Transaction Format"},"145":{"body":"A channel frame is encoded as: frame = channel_id ++ frame_number ++ frame_data_length ++ frame_data ++ is_last channel_id = bytes16\nframe_number = uint16\nframe_data_length = uint32\nframe_data = bytes\nis_last = bool Where uint32 and uint16 are all big-endian unsigned integers. Type names should be interpreted to and encoded according to the Solidity ABI . All data in a frame is fixed-size, except the frame_data. The fixed overhead is 16 + 2 + 4 + 1 = 23 bytes. Fixed-size frame metadata avoids a circular dependency with the target total data length, to simplify packing of frames with varying content length. where: channel_id is an opaque identifier for the channel. It should not be reused and is suggested to be random; however, outside of timeout rules, it is not checked for validity frame_number identifies the index of the frame within the channel frame_data_length is the length of frame_data in bytes. It is capped to 1,000,000 bytes. frame_data is a sequence of bytes belonging to the channel, logically after the bytes from the previous frames is_last is a single byte with a value of 1 if the frame is the last in the channel, 0 if there are frames in the channel. Any other value makes the frame invalid (it must be ignored by the rollup node).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Format","id":"145","title":"Frame Format"},"146":{"body":"A channel is encoded by applying a streaming compression algorithm to a list of batches: rlp_batches = []\nfor batch in batches: rlp_batches.append(batch) where: batches is the input, a sequence of batches byte-encoded as per the next section (\"Batch Encoding\") rlp_batches is the concatenation of the RLP-encoded batches channel_encoding = zlib_compress(rlp_batches) where zlib_compress is the ZLIB algorithm (as specified in RFC-1950 ) with no dictionary. The Fjord upgrade introduces an additional versioned channel encoding format to support alternate compression algorithms. When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL (defined in the Protocol Parameters table ), in order to avoid \"zip-bomb\" types of attack (where a small compressed input decompresses to a humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained only the first MAX_RLP_BYTES_PER_CHANNEL decompressed bytes. The limit is set on RLP decoding, so all batches that can be decoded in MAX_RLP_BYTES_PER_CHANNEL will be accepted even if the size of the channel is greater than MAX_RLP_BYTES_PER_CHANNEL. The exact requirement is that length(input) <= MAX_RLP_BYTES_PER_CHANNEL. While the above pseudocode implies that all batches are known in advance, it is possible to perform streaming compression and decompression of RLP-encoded batches. This means it is possible to start including channel frames in a batcher transaction before we know how many batches (and how many frames) the channel will contain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Format","id":"146","title":"Channel Format"},"147":{"body":"Recall that a batch contains a list of transactions to be included in a specific L2 block. A batch is encoded as batch_version ++ content, where content depends on the batch_version. Prior to the Delta upgrade, batches all have batch_version 0 and are encoded as described below. batch_version content 0 rlp_encode([parent_hash, epoch_number, epoch_hash, timestamp, transaction_list]) where: batch_version is a single byte, prefixed before the RLP contents, alike to transaction typing. rlp_encode is a function that encodes a batch according to the RLP format , and [x, y, z] denotes a list containing items x, y and z parent_hash is the block hash of the previous L2 block epoch_number and epoch_hash are the number and hash of the L1 block corresponding to the sequencing epoch of the L2 block timestamp is the timestamp of the L2 block transaction_list is an RLP-encoded list of EIP-2718 encoded transactions. The Delta upgrade introduced an additional batch type, span batches . Unknown versions make the batch invalid (it must be ignored by the rollup node), as do malformed contents. The epoch_number and the timestamp must also respect the constraints listed in the Batch Queue section, otherwise the batch is considered invalid and will be ignored.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Format","id":"147","title":"Batch Format"},"148":{"body":"The above primarily describes the general encodings used in L2 chain derivation, primarily how batches are encoded within batcher transactions . This section describes how the L2 chain is produced from the L1 batches using a pipeline architecture. A verifier may implement this differently, but must be semantically equivalent to not diverge from the L2 chain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Architecture","id":"148","title":"Architecture"},"149":{"body":"Our architecture decomposes the derivation process into a pipeline made up of the following stages: L1 Traversal L1 Retrieval Frame Queue Channel Bank Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue The data flows from the start (outer) of the pipeline towards the end (inner). From the innermost stage the data is pulled from the outermost stage. However, data is processed in reverse order. Meaning that if there is any data to be processed in the last stage, it will be processed first. Processing proceeds in \"steps\" that can be taken at each stage. We try to take as many steps as possible in the last (most inner) stage before taking any steps in its outer stage, etc. This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing the derivation pipeline. Each stage can maintain its own inner state as necessary. In particular, each stage maintains a L1 block reference (number + hash) to the latest L1 block such that all data originating from previous blocks has been fully processed, and the data from that block is being or has been processed. This allows the innermost stage to account for finalization of the L1 data-availability used to produce the L2 chain, to reflect in the L2 chain forkchoice when the L2 chain inputs become irreversible. Let's briefly describe each stage of the pipeline.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Pipeline","id":"149","title":"L2 Chain Derivation Pipeline"},"15":{"body":"Users are the general class of network participants who: Submit transactions through a Sequencer or by interacting with contracts on Ethereum. Query transaction data from interfaces operated by verifiers.","breadcrumbs":"Background » Users","id":"15","title":"Users"},"150":{"body":"In the L1 Traversal stage, we simply read the header of the next L1 block. In normal operations, these will be new L1 blocks as they get created, though we can also read old blocks while syncing, or in case of an L1 re-org . Upon traversal of the L1 block, the system configuration copy used by the L1 retrieval stage is updated, such that the batch-sender authentication is always accurate to the exact L1 block that is read by the stage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Traversal","id":"150","title":"L1 Traversal"},"151":{"body":"In the L1 Retrieval stage, we read the block we get from the outer stage (L1 traversal), and extract data from its batcher transactions . A batcher transaction is one with the following properties: The to field is equal to the configured batcher inbox address. The sender, as recovered from the transaction signature (v, r, and s), is the batcher address loaded from the system config matching the L1 block of the data. Each batcher transaction is versioned and contains a series of channel frames to be read by the Frame Queue, see Batch Submission Wire Format . Each batcher transaction in the block is processed in the order they appear in the block by passing its calldata on to the next phase.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Retrieval","id":"151","title":"L1 Retrieval"},"152":{"body":"The Frame Queue buffers one data-transaction at a time, decoded into channel frames , to be consumed by the next stage. See Batcher transaction format and Frame format specifications.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Queue","id":"152","title":"Frame Queue"},"153":{"body":"The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1 retrieval stage. A step in the channel bank stage tries to read data from channels that are \"ready\". Channels are currently fully buffered until read or dropped, streaming channels may be supported in a future version of the ChannelBank. To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels. Channels are recorded in FIFO order in a structure called the channel queue . A channel is added to the channel queue the first time a frame belonging to the channel is seen. Pruning After successfully inserting a new frame, the ChannelBank is pruned: channels are dropped in FIFO order, until total_size <= MAX_CHANNEL_BANK_SIZE, where: total_size is the sum of the sizes of each channel, which is the sum of all buffered frame data of the channel, with an additional frame-overhead of 200 bytes per frame. MAX_CHANNEL_BANK_SIZE is a protocol constant defined in the Protocol Parameters table . Timeouts The L1 origin that the channel was opened in is tracked with the channel as channel.open_l1_block, and determines the maximum span of L1 blocks that the channel data is retained for, before being pruned. A channel is timed out if: current_l1_block.number > channel.open_l1_block.number + CHANNEL_TIMEOUT, where: current_l1_block is the L1 origin that the stage is currently traversing. CHANNEL_TIMEOUT is a rollup-configurable, expressed in number of L1 blocks. New frames for timed-out channels are dropped instead of buffered. Reading Upon reading, while the first opened channel is timed-out, remove it from the channel-bank. Prior to the Canyon network upgrade, once the first opened channel, if any, is not timed-out and is ready, then it is read and removed from the channel-bank. After the Canyon network upgrade, the entire channel bank is scanned in FIFO order (by open time) & the first ready (i.e. not timed-out) channel will be returned. The canyon behavior will activate when frames from a L1 block whose timestamp is greater than or equal to the canyon time first enter the channel queue. A channel is ready if: The channel is closed The channel has a contiguous sequence of frames until the closing frame If no channel is ready, the next frame is read and ingested into the channel bank. Loading frames When a channel ID referenced by a frame is not already present in the Channel Bank, a new channel is opened, tagged with the current L1 block, and appended to the channel-queue. Frame insertion conditions: New frames matching timed-out channels that have not yet been pruned from the channel-bank are dropped. Duplicate frames (by frame number) for frames that have not been pruned from the channel-bank are dropped. Duplicate closes (new frame is_last == 1, but the channel has already seen a closing frame and has not yet been pruned from the channel-bank) are dropped. If a frame is closing (is_last == 1) any existing higher-numbered frames are removed from the channel. Note that while this allows channel IDs to be reused once they have been pruned from the channel-bank, it is recommended that batcher implementations use unique channel IDs.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Bank","id":"153","title":"Channel Bank"},"154":{"body":"In this stage, we decompress the channel we pull from the last stage, and then parse batches from the decompressed byte stream. See Channel Format and Batch Format for decompression and decoding specification.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Reader (Batch Decoding)","id":"154","title":"Channel Reader (Batch Decoding)"},"155":{"body":"During the Batch Buffering stage, we reorder batches by their timestamps. If batches are missing for some time slots and a valid batch with a higher timestamp exists, this stage also generates empty batches to fill the gaps. Batches are pushed to the next stage whenever there is one sequential batch directly following the timestamp of the current safe L2 head (the last block that can be derived from the canonical L1 chain). The parent hash of the batch must also match the hash of the current safe L2 head. Note that the presence of any gaps in the batches derived from L1 means that this stage will need to buffer for a whole sequencing window before it can generate empty batches (because the missing batch(es) could have data in the last L1 block of the window in the worst case). A batch can have 4 different forms of validity: drop: the batch is invalid, and will always be in the future, unless we reorg. It can be removed from the buffer. accept: the batch is valid and should be processed. undecided: we are lacking L1 information until we can proceed batch filtering. future: the batch may be valid, but cannot be processed yet and should be checked again later. The batches are processed in order of the inclusion on L1: if multiple batches can be accept-ed the first is applied. An implementation can defer future batches a later derivation step to reduce validation work. The batches validity is derived as follows: Definitions: batch as defined in the Batch format section . epoch = safe_l2_head.l1_origin a L1 origin coupled to the batch, with properties: number (L1 block number), hash (L1 block hash), and timestamp (L1 block timestamp). inclusion_block_number is the L1 block number when batch was first fully derived, i.e. decoded and output by the previous stage. next_timestamp = safe_l2_head.timestamp + block_time is the expected L2 timestamp the next batch should have, see block time information . next_epoch may not be known yet, but would be the L1 block after epoch if available. batch_origin is either epoch or next_epoch, depending on validation. Note that processing of a batch can be deferred until batch.timestamp <= next_timestamp, since future batches will have to be retained anyway. Rules, in validation order: batch.timestamp > next_timestamp -> future: i.e. the batch must be ready to process. batch.timestamp < next_timestamp -> drop: i.e. the batch must not be too old. batch.parent_hash != safe_l2_head.hash -> drop: i.e. the parent hash must be equal to the L2 safe head block hash. batch.epoch_num + sequence_window_size < inclusion_block_number -> drop: i.e. the batch must be included timely. batch.epoch_num < epoch.number -> drop: i.e. the batch origin is not older than that of the L2 safe head. batch.epoch_num == epoch.number: define batch_origin as epoch. batch.epoch_num == epoch.number+1: If next_epoch is not known -> undecided: i.e. a batch that changes the L1 origin cannot be processed until we have the L1 origin data. If known, then define batch_origin as next_epoch batch.epoch_num > epoch.number+1 -> drop: i.e. the L1 origin cannot change by more than one L1 block per L2 block. batch.epoch_hash != batch_origin.hash -> drop: i.e. a batch must reference a canonical L1 origin, to prevent batches from being replayed onto unexpected L1 chains. batch.timestamp < batch_origin.time -> drop: enforce the min L2 timestamp rule. batch.timestamp > batch_origin.time + max_sequencer_drift: enforce the L2 timestamp drift rule, but with exceptions to preserve above min L2 timestamp invariant: len(batch.transactions) == 0: epoch.number == batch.epoch_num: this implies the batch does not already advance the L1 origin, and must thus be checked against next_epoch. If next_epoch is not known -> undecided: without the next L1 origin we cannot yet determine if time invariant could have been kept. If batch.timestamp >= next_epoch.time -> drop: the batch could have adopted the next L1 origin without breaking the L2 time >= L1 time invariant. len(batch.transactions) > 0: -> drop: when exceeding the sequencer time drift, never allow the sequencer to include transactions. batch.transactions: drop if the batch.transactions list contains a transaction that is invalid or derived by other means exclusively: any transaction that is empty (zero length byte string) any deposited transactions (identified by the transaction type prefix byte) If no batch can be accept-ed, and the stage has completed buffering of all batches that can fully be read from the L1 block at height epoch.number + sequence_window_size, and the next_epoch is available, then an empty batch can be derived with the following properties: parent_hash = safe_l2_head.hash timestamp = next_timestamp transactions is empty, i.e. no sequencer transactions. Deposited transactions may be added in the next stage. If next_timestamp < next_epoch.time: the current L1 origin is repeated, to preserve the L2 time invariant. epoch_num = epoch.number epoch_hash = epoch.hash If the batch is the first batch of the epoch, that epoch is used instead of advancing the epoch to ensure that there is at least one L2 block per epoch. epoch_num = epoch.number epoch_hash = epoch.hash Otherwise, epoch_num = next_epoch.number epoch_hash = next_epoch.hash","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Queue","id":"155","title":"Batch Queue"},"156":{"body":"In the Payload Attributes Derivation stage, we convert the batches we get from the previous stage into instances of the PayloadAttributes structure. Such a structure encodes the transactions that need to figure into a block, as well as other block inputs (timestamp, fee recipient, etc). Payload attributes derivation is detailed in the section Deriving Payload Attributes section below. This stage maintains its own copy of the system configuration , independent of the L1 retrieval stage. The system configuration is updated with L1 log events whenever the L1 epoch referenced by the batch input changes.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Payload Attributes Derivation","id":"156","title":"Payload Attributes Derivation"},"157":{"body":"In the Engine Queue stage, the previously derived PayloadAttributes structures are buffered and sent to the execution engine to be executed and converted into a proper L2 block. The stage maintains references to three L2 blocks: The finalized L2 head : everything up to and including this block can be fully derived from the finalized (i.e. canonical and forever irreversible) part of the L1 chain. The safe L2 head : everything up to and including this block can be fully derived from the currently canonical L1 chain. The unsafe L2 head : blocks between the safe and unsafe heads are unsafe blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer mode) or from unsafe sync to the sequencer (in validator mode). This is also known as the \"latest\" head. Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references from which L1 blocks each was derived. This history does not have to be complete, but enables later L1 finality signals to be translated into L2 finality. Engine API usage To interact with the engine, the execution engine API is used, with the following JSON-RPC methods: Bedrock, Canyon, Delta: API Usage engine_forkchoiceUpdatedV2 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV2 — retrieves a previously requested execution payload build. engine_newPayloadV2 — executes an execution payload to create a block. Ecotone: API Usage engine_forkchoiceUpdatedV3 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV3 — retrieves a previously requested execution payload build. engine_newPayload engine_newPayloadV2 — executes a Bedrock/Canyon/Delta execution payload to create a block. engine_newPayloadV3 — executes an Ecotone execution payload to create a block. The current version of op-node uses the v3 Engine API RPC methods as well as engine_newPayloadV2, due to engine_newPayloadV3 only supporting Ecotone execution payloads. Both engine_forkchoiceUpdatedV3 and engine_getPayloadV3 are backwards compatible with Bedrock, Canyon & Delta payloads. Prior versions of op-node used v2 and v1 methods. The execution payload is an object of type ExecutionPayloadV3 . The ExecutionPayload has the following requirements: Bedrock The withdrawals field MUST be nil The blob gas used field MUST be nil The blob gas limit field MUST be nil Canyon, Delta The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be nil The blob gas limit field MUST be nil Ecotone The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be 0 The blob gas limit field MUST be 0 Forkchoice synchronization If there are any forkchoice updates to be applied, before additional inputs are derived or processed, then these are applied to the engine first. This synchronization may happen when: A L1 finality signal finalizes one or more L2 blocks: updating the \"finalized\" L2 block. A successful consolidation of unsafe L2 blocks: updating the \"safe\" L2 block. The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state. The new forkchoice state is applied by calling fork choice updated on the engine API. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. L1-consolidation: payload attributes matching If the unsafe head is ahead of the safe head, then consolidation is attempted, verifying that existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data. During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If the payload attributes match this oldest unsafe L2 block, then that block can be considered \"safe\" and becomes the new safe head. The following fields of the derived L2 payload attributes are checked for equality with the L2 block: Bedrock, Canyon, Delta, Ecotone Blocks parent_hash timestamp randao fee_recipient transactions_list (first length, then equality of each of the encoded transactions, including deposits) gas_limit Canyon, Delta, Ecotone Blocks withdrawals (first presence, then length, then equality of each of the encoded withdrawals) Ecotone Blocks parent_beacon_block_root If consolidation succeeds, the forkchoice change will synchronize as described in the section above. If consolidation fails, the L2 payload attributes will be processed immediately as described in the section below. The payload attributes are chosen in favor of the previous unsafe L2 block, creating an L2 chain reorg on top of the current safe block. Immediately processing the new alternative attributes enables execution engines like go-ethereum to enact the change, as linear rewinds of the tip of the chain may not be supported. L1-sync: payload attributes processing If the safe and unsafe L2 heads are identical (whether because of failed consolidation or not), we send the L2 payload attributes to the execution engine to be constructed into a proper L2 block. This L2 block will then become both the new L2 safe and unsafe head. If a payload attributes created from a batch cannot be inserted into the chain because of a validation error (i.e. there was an invalid transaction or state transition in the block) the batch should be dropped & the safe head should not be advanced. The engine queue will attempt to use the next batch for that timestamp from the batch queue. If no valid batch is found, the rollup node will create a deposit only batch which should always pass validation because deposits are always valid. Interaction with the execution engine via the execution engine API is detailed in the Communication with the Execution Engine section. The payload attributes are then processed with a sequence of: Engine: Fork choice updated with current forkchoice state of the stage, and the attributes to start block building. Non-deterministic sources, like the tx-pool, must be disabled to reconstruct the expected block. Engine: Get Payload to retrieve the payload, by the payload-ID in the result of the previous step. Engine: New Payload to import the new payload into the execution engine. Engine: Fork Choice Updated to make the new payload canonical, now with a change of both safe and unsafe fields to refer to the payload, and no payload attributes. Engine API Error handling: On RPC-type errors the payload attributes processing should be re-attempted in a future step. On payload processing errors the attributes must be dropped, and the forkchoice state must be left unchanged. Eventually the derivation pipeline will produce alternative payload attributes, with or without batches. If the payload attributes only contained deposits, then it is a critical derivation error if these are invalid. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. Processing unsafe payload attributes If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as an \"unsafe\" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the user to see the head of the L2 chain faster than the L1 may confirm the L2 batches. To process unsafe payloads, the payload must: Have a block number higher than the current safe L2 head. The safe L2 head may only be reorged out due to L1 reorgs. Have a parent blockhash that matches the current unsafe L2 head. This prevents the execution engine individually syncing a larger gap in the unsafe L2 chain. This prevents unsafe L2 blocks from reorging other previously validated L2 blocks. This check may change in the future versions to adopt e.g. the L1 snap-sync protocol. The payload is then processed with a sequence of: Bedrock/Canyon/Delta Payloads engine_newPayloadV2: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV2: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Ecotone Payloads engine_newPayloadV3: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV3: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Engine API Error handling: On RPC-type errors the payload processing should be re-attempted in a future step. On payload processing errors the payload must be dropped, and not be marked as canonical. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Engine Queue","id":"157","title":"Engine Queue"},"158":{"body":"It is possible to reset the pipeline, for instance if we detect an L1 reorg (reorganization) . This enables the rollup node to handle L1 chain reorg events. Resetting will recover the pipeline into a state that produces the same outputs as a full L2 derivation process, but starting from an existing L2 chain that is traversed back just enough to reconcile with the current L1 chain. Note that this algorithm covers several important use-cases: Initialize the pipeline without starting from 0, e.g. when the rollup node restarts with an existing engine instance. Recover the pipeline if it becomes inconsistent with the execution engine chain, e.g. when the engine syncs/changes. Recover the pipeline when the L1 chain reorganizes, e.g. a late L1 block is orphaned, or a larger attestation failure. Initialize the pipeline to derive a disputed L2 block with prior L1 and L2 history inside a fault-proof program. Handling these cases also means a node can be configured to eagerly sync L1 data with 0 confirmations, as it can undo the changes if the L1 later does recognize the data as canonical, enabling safe low-latency usage. The Engine Queue is first reset, to determine the L1 and L2 starting points to continue derivation from. After this, the other stages are reset independent of each other. Finding the sync starting point To find the starting point, there are several steps, relative to the head of the chain traversing back: Find the current L2 forkchoice state If no finalized block can be found, start at the Bedrock genesis block. If no safe block can be found, fallback to the finalized block. The unsafe block should always be available and consistent with the above (it may not be in rare engine-corruption recovery cases, this is being reviewed). Find the first L2 block with plausible L1 reference to be the new unsafe starting point, starting from previous unsafe, back to finalized and no further. Plausible iff: the L1 origin of the L2 block is known and canonical, or unknown and has a block-number ahead of L1. Find the first L2 block with an L1 reference older than the sequencing window, to be the new safe starting point, starting at the above plausible unsafe head, back to finalized and no further. If at any point the L1 origin is known but not canonical, the unsafe head is revised to parent of the current. The highest L2 block with known canonical L1 origin is remembered as highest. If at any point the L1 origin in the block is corrupt w.r.t. derivation rules, then error. Corruption includes: Inconsistent L1 origin block number or parent-hash with parent L1 origin Inconsistent L1 sequence number (always changes to 0 for a L1 origin change, or increments by 1 if not) If the L1 origin of the L2 block n is older than the L1 origin of highest by more than a sequence window, and n.sequence_number == 0, then the parent L2 block of n will be the safe starting point. The finalized L2 block persists as the finalized starting point. Find the first L2 block with an L1 reference older than the channel-timeout The L1 origin referenced by this block which we call l2base will be the base for the L2 pipeline derivation: By starting here, the stages can buffer any necessary data, while dropping incomplete derivation outputs until L1 traversal has caught up with the actual L2 safe head. While traversing back the L2 chain, an implementation may sanity-check that the starting point is never set too far back compared to the existing forkchoice state, to avoid an intensive reorg because of misconfiguration. Implementers note: step 1-4 are known as FindL2Heads. Step 5 is currently part of the Engine Queue reset. This may change to isolate the starting-point search from the bare reset logic. Resetting derivation stages L1 Traversal: start at L1 base as first block to be pulled by next stage. L1 Retrieval: empty previous data, and fetch the base L1 data, or defer the fetching work to a later pipeline step. Frame Queue: empty the queue. Channel Bank: empty the channel bank. Channel Reader: reset any batch decoding state. Batch Queue: empty the batch queue, use base as initial L1 point of reference. Payload Attributes Derivation: empty any batch/attributes state. Engine Queue: Initialize L2 forkchoice state with syncing start point state. (finalized/safe/unsafe) Initialize the L1 point of reference of the stage to base. Require a forkchoice update as first task Reset any finality data Where necessary, stages starting at base can initialize their system-config from data encoded in the l2base block. About reorgs Post-Merge Note that post- merge , the depth of reorgs will be bounded by the L1 finality delay (2 L1 beacon epochs, or approximately 13 minutes, unless more than 1/3 of the network consistently disagrees). New L1 blocks may be finalized every L1 beacon epoch (approximately 6.4 minutes), and depending on these finality-signals and batch-inclusion, the derived L2 chain will become irreversible as well. Note that this form of finalization only affects inputs, and nodes can then subjectively say the chain is irreversible, by reproducing the chain from these irreversible inputs and the set protocol rules and parameters. This is however completely unrelated to the outputs posted on L1, which require a form of proof like a fault-proof or zk-proof to finalize. Optimistic-rollup outputs like withdrawals on L1 are only labeled \"finalized\" after passing a week without dispute (fault proof challenge window), a name-collision with the proof-of-stake finalization.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Resetting the Pipeline","id":"158","title":"Resetting the Pipeline"},"159":{"body":"For every L2 block derived from L1 data, we need to build payload attributes , represented by an expanded version of the PayloadAttributesV2 object, which includes additional transactions and noTxPool fields. This process happens during the payloads-attributes queue ran by a verifier node, as well as during block-production ran by a sequencer node (the sequencer may enable the tx-pool usage if the transactions are batch-submitted).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving Payload Attributes","id":"159","title":"Deriving Payload Attributes"},"16":{"body":"Sequencers fill the role of the block producer on an OP Stack chain. Chains may have a single Sequencer or may choose to utilize some consensus protocol that coordinates multiple Sequencers. The OP Stack currently officially only supports a single active Sequencer at any given time. In general, specifications may use the term \"the Sequencer\" as a stand-in for either a single Sequencer or a consensus protocol of multiple Sequencers. The Sequencer: Accepts transactions directly from Users. Observes \"deposit\" transactions generated on Ethereum. Consolidates both transaction streams into ordered L2 blocks. Submits information to L1 that is sufficient to fully reproduce those L2 blocks. Provides real-time access to pending L2 blocks that have not yet been confirmed on L1. The Sequencer serves an important role for the operation of an L2 chain but is not a trusted actor. The Sequencer is generally responsible for improving the user experience by ordering transactions much more quickly and cheaply than would currently be possible if users were to submit all transactions directly to L1.","breadcrumbs":"Background » Sequencers","id":"16","title":"Sequencers"},"160":{"body":"For each L2 block to be created by the sequencer, we start from a sequencer batch matching the target L2 block number. This could potentially be an empty auto-generated batch, if the L1 chain did not include a batch for the target L2 block number. Remember that the batch includes a sequencing epoch number, an L2 timestamp, and a transaction list. This block is part of a sequencing epoch , whose number matches that of an L1 block (its L1 origin ). This L1 block is used to derive L1 attributes and (for the first L2 block in the epoch) user deposits. Therefore, a PayloadAttributesV2 object must include the following transactions: one or more deposited transactions , of two kinds: a single L1 attributes deposited transaction , derived from the L1 origin. for the first L2 block in the epoch, zero or more user-deposited transactions , derived from the receipts of the L1 origin. zero or more network upgrade automation transactions : special transactions to perform network upgrades. zero or more sequenced transactions : regular transactions signed by L2 users, included in the sequencer batch. Transactions must appear in this order in the payload attributes. The L1 attributes are read from the L1 block header, while deposits are read from the L1 block's receipts . Refer to the deposit contract specification for details on how deposits are encoded as log entries.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving the Transaction List","id":"160","title":"Deriving the Transaction List"},"161":{"body":"Some network upgrades require automated contract changes or deployments at specific blocks. To automate these, without adding persistent changes to the execution-layer, special transactions may be inserted as part of the derivation process. Ecotone The Ecotone hardfork activation block contains the following transactions, in this order: L1 Attributes Transaction, using the pre-Ecotone setL1BlockValues User deposits from L1 Network Upgrade Transactions L1Block deployment GasPriceOracle deployment Update L1Block Proxy ERC-1967 Implementation Slot Update GasPriceOracle Proxy ERC-1967 Implementation Slot GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) To not modify or interrupt the system behavior around gas computation, this block will not include any sequenced transactions by setting noTxPool: true. L1Block Deployment The L1Block contract is upgraded to process the new Ecotone L1-data-fee parameters and L1 blob base-fee. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000000 to: null mint: 0 value: 0 gasLimit: 375,000 data: 0x60806040523480156100105... ( full bytecode ) sourceHash: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Deployment\" This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000000\nComputed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Deployment\"))\n# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json This transaction MUST deploy a contract with the following code hash 0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd. GasPriceOracle Deployment The GasPriceOracle contract is upgraded to support the new Ecotone L1-data-fee parameters. Post fork this contract will use the blob base fee to compute the gas price for L1-data-fee transactions. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000001 to: null, mint: 0 value: 0 gasLimit: 1,000,000 data: 0x60806040523480156100... ( full bytecode ) sourceHash: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Deployment\" This results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000001\nComputed Address: 0xb528D11cC114E026F138fE568744c6D45ce6Da7A Verify sourceHash: ❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Deployment\"))\n# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json This transaction MUST deploy a contract with the following code hash 0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5. L1Block Proxy Update This transaction updates the L1Block Proxy ERC-1967 implementation slot to point to the new L1Block deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x4200000000000000000000000000000000000015 (L1Block Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff sourceHash: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)\n0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Proxy Update\"))\n# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc GasPriceOracle Proxy Update This transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a sourceHash: 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: Gas Price Oracle Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)\n0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Proxy Update\"))\n# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a GasPriceOracle Enable Ecotone This transaction informs the GasPriceOracle to start using the Ecotone gas calculation formula. A deposit transaction is derived with the following attributes: from: 0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 (Depositer Account) to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 80,000 data: 0x22b90ab3 sourceHash: 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Set Ecotone\" Verify data: cast sig \"setEcotone()\"\n0x22b90ab3 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Set Ecotone\"))\n# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93 Beacon block roots contract deployment (EIP-4788) EIP-4788 introduces a \"Beacon block roots\" contract, that processes and exposes the beacon-block-root values. at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02. For deployment, EIP-4788 defines a pre- EIP-155 legacy transaction, sent from a key that is derived such that the transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code. However, this type of transaction requires manual deployment and gas-payments. And since the processing is an integral part of the chain processing, and has to be repeated for every OP-Stack chain, the deployment is approached differently here. Some chains may already have a user-submitted instance of the EIP-4788 transaction. This is cryptographically guaranteed to be correct, but may result in the upgrade transaction deploying a second contract, with the next nonce. The result of this deployment can be ignored. A Deposit transaction is derived with the following attributes: from: 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875, as specified in the EIP. to: null mint: 0 value: 0 gasLimit: 0x3d090, as specified in the EIP. isCreation: true data: 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500 isSystemTx: false, as per the Regolith upgrade, even the system-generated transactions spend gas. sourceHash: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c, computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: beacon block roots contract deployment\" The contract address upon deployment is computed as rlp([sender, nonce]), which will equal: BEACON_ROOTS_ADDRESS if deployed a different address (0xE3aE1Ae551eeEda337c0BfF6C4c7cbA98dce353B) if nonce = 1: when a user already submitted the EIP transaction before the upgrade. Verify BEACON_ROOTS_ADDRESS: cast compute-address --nonce=0 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875\n# Computed Address: 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: beacon block roots contract deployment\"))\n# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Network upgrade automation transactions","id":"161","title":"Network upgrade automation transactions"},"162":{"body":"After deriving the transactions list, the rollup node constructs a PayloadAttributesV2 as follows: timestamp is set to the batch's timestamp. random is set to the prev_randao L1 block attribute. suggestedFeeRecipient is set to the Sequencer Fee Vault address. See Fee Vaults specification. transactions is the array of the derived transactions: deposited transactions and sequenced transactions, all encoded with EIP-2718 . noTxPool is set to true, to use the exact above transactions list when constructing the block. gasLimit is set to the current gasLimit value in the system configuration of this payload. withdrawals is set to nil prior to Canyon and an empty array after Canyon","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Building Individual Payload Attributes","id":"162","title":"Building Individual Payload Attributes"},"163":{"body":"Table of Contents Overview","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Batch Submitter","id":"163","title":"Batch Submitter"},"164":{"body":"The batch submitter, also referred to as the batcher, is the entity submitting the L2 sequencer data to L1, to make it available for verifiers. The format of the data transactions is defined in the derivation spec : the data is constructed from L2 blocks in the reverse order as it is derived from data into L2 blocks. The timing, operation and transaction signing is implementation-specific: any data can be submitted at any time, but only the data that matches the derivation spec rules will be valid from the verifier perspective. The most minimal batcher implementation can be defined as a loop of the following operations: See if the unsafe L2 block number is past the safe block number: unsafe data needs to be submitted. Iterate over all unsafe L2 blocks, skip any that were previously submitted. Open a channel, buffer all the L2 block data to be submitted, while applying the encoding and compression as defined in the derivation spec . Pull frames from the channel to fill data transactions with, until the channel is empty. Submit the data transactions to L1 The L2 view of safe/unsafe does not instantly update after data is submitted, nor when it gets confirmed on L1, so special care may have to be taken to not duplicate data submissions.","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Overview","id":"164","title":"Overview"},"165":{"body":"Table of Contents Overview Pre-image Oracle Pre-image key types Type 0: Zero key Type 1: Local key Type 2: Global keccak256 key Type 3: Global generic key Type 4: Global SHA2-256 key Type 5: Global EIP-4844 Point-evaluation key Type 6: Global Precompile key Type 7-128: reserved range Type 129-255: application usage Bootstrapping Hinting Pre-image communication Fault Proof Program Prologue Main content Epilogue Pre-image hinting routes l1-block-header l1-transactions l1-receipts l1-precompile l2-block-header l2-transactions l2-code l2-state-node l2-output Precompile Accelerators Fault Proof VM Fault Proof Interactive Dispute Game","breadcrumbs":"OP Stack Protocol » Fault Proof » Fault Proof","id":"165","title":"Fault Proof"},"166":{"body":"A fault proof, also known as fraud proof or interactive game, consists of 3 components: Program : given a commitment to all rollup inputs (L1 data) and the dispute, verify the dispute statelessly. VM : given a stateless program and its inputs, trace any instruction step, and prove it on L1. Interactive Dispute Game : bisect a dispute down to a single instruction, and resolve the base-case using the VM. Each of these 3 components may have different implementations, which can be combined into different proof stacks, and contribute to proof diversity when resolving a dispute. \"Stateless execution\" of the program, and its individual instructions, refers to reproducing the exact same computation by authenticating the inputs with a Pre-image Oracle . Diagram of Program and VM architecture","breadcrumbs":"OP Stack Protocol » Fault Proof » Overview","id":"166","title":"Overview"},"167":{"body":"The pre-image oracle is the only form of communication between the Program (in the Client role) and the VM (in the Server role). The program uses the pre-image oracle to query any input data that is understood to be available to the user: The initial inputs to bootstrap the program. See Bootstrapping . External data not already part of the program code. See Pre-image hinting routes . The communication happens over a simple request-response wire protocol, see Pre-image communication .","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image Oracle","id":"167","title":"Pre-image Oracle"},"168":{"body":"Pre-images are identified by a bytes32 type-prefixed key: The first byte identifies the type of request. The remaining 31 bytes identify the pre-image key. Type 0: Zero key The zero prefix is illegal. This ensures all pre-image keys are non-zero, enabling storage lookup optimizations and avoiding easy mistakes with invalid zeroed keys in the EVM. Type 1: Local key Information specific to the dispute: the remainder of the key may be an index, a string, a hash, etc. Only the contract(s) managing this dispute instance may serve the value for this key: it is localized and context-dependent. This type of key is used for program bootstrapping, to identify the initial input arguments by index or name. Type 2: Global keccak256 key This type of key uses a global pre-image store contract, and is fully context-independent and permissionless. I.e. every key must have a single unique value, regardless of chain history or time. Using a global store reduces duplicate pre-image registration work, and avoids unnecessary contract redeployments per dispute. This global store contract should be non-upgradeable. Since keccak256 is a safe 32-byte hash input, the first byte is overwritten with a 2 to derive the key, while keeping the rest of the key \"readable\" (matching the original hash). Type 3: Global generic key Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments. This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:], where: x is a bytes32, which can be a hash of an arbitrary-length type of cryptographically secure commitment. sender is a bytes32 identifying the pre-image inserter address (left-padded to 32 bytes) This global store contract should be non-upgradeable. The global contract is permissionless: users can standardize around external contracts that verify pre-images (i.e. a specific sender will always be trusted for a specific kind of pre-image). The external contract verifies the pre-image before inserting it into the global store for usage by all fault proof VMs without requiring the VM or global store contract to be changed. Users may standardize around upgradeable external pre-image contracts, in case the implementation of the verification of the pre-image is expected to change. The store update function is update(x bytes32, offset uint64, span uint8, value bytes32): x is the bytes32 x that the pre-image key is computed with. Only part of the pre-image, starting at offset, and up to (incl.) 32 bytes span can be inserted at a time. Pre-images may have an undefined length (e.g. a stream), we only need to know how many bytes of value are usable. The key and offset will be hashed together to uniquely store the value and span, for later pre-image serving. This enables fault proof programs to adopt any new pre-image schemes without VM update or contract redeployment. It is up to the user to index the special pre-image values by this key scheme, as there is no way to revert it to the original commitment without knowing said commitment or value. Type 4: Global SHA2-256 key A SHA-256 pre-image. Key: the SHA-256 hash, with the first byte overwritten with the type byte: 4 ++ sha256(data)[1:]. Type 5: Global EIP-4844 Point-evaluation key An EIP-4844 point-evaluation. In an EIP-4844 blob, 4096 field elements represent the blob data. It verifies p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof. The value y is the pre-image. The value z is part of the key; the index of the point within the blob. The commitment is part of the key. Each element is proven with a point-evaluation. Key: 5 ++ keccak256(commitment ++ z)[1:], where: 5 is the type byte ++ is concatenation commitment is a bytes48, representing the KZG commitment. z is a big-endian uint256 Type 6: Global Precompile key A precompile result. It maps directly to precompiles on Ethereum. This preimage key can be used to avoid running expensive precompile operations in the program. Key: 6 ++ keccak256(precompile ++ input)[1:], where: 6 is the type byte ++ is concatenation precompile is the 20-byte address of the precompile contract input is the input to the precompile contract The result is identical to that of a call to the precompile contract, prefixed with a revert indicator: reverted ++ precompile_result. reverted is a 1-byte indicator with a 0 value if the precompile reverts for the given input, otherwise it's 1. Type 7-128: reserved range Range start and end both inclusive. This range of key types is reserved for future usage by the core protocol. E.g. version changes, contract migrations, chain-data, additional core features, etc. 128 specifically (1000 0000 in binary) is reserved for key-type length-extension (reducing the content part to 30 or less key bytes), if the need arises. Type 129-255: application usage This range of key types may be used by forks or customized versions of the fault proof protocol.","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image key types","id":"168","title":"Pre-image key types"},"169":{"body":"Initial inputs are deterministic, but not necessarily singular or global: there may be multiple different disputes at the same time, each with its own disputed claims and L1 context. To bootstrap, the program requests the initial inputs from the VM, using pre-image key type 1. The VM is aware of the external context, and maps requested pre-image keys based on their type, i.e. a local lookup for type 1, or global one for 2, and optionally support other key-types.","breadcrumbs":"OP Stack Protocol » Fault Proof » Bootstrapping","id":"169","title":"Bootstrapping"},"17":{"body":"Verifiers download and execute the L2 state transition function independently of the Sequencer. Verifiers help to maintain the integrity of the network and serve blockchain data to Users. Verifiers generally: Download rollup data from L1 and the Sequencer. Use rollup data to execute the L2 state transition function. Serve rollup data and computed L2 state information to Users. Verifiers can also act as Proposers and/or Challengers who: Submit assertions about the state of the L2 to a smart contract on L1. Validate assertions made by other participants. Dispute invalid assertions made by other participants.","breadcrumbs":"Background » Verifiers","id":"17","title":"Verifiers"},"170":{"body":"There is one more form of optional communication between client and server: pre-image hinting. Hinting is optional, and is a no-op in a L1 VM implementation. The hint itself comes at very low cost onchain: the hint can be a single write sys-call, which is instant as the memory to write as hint does not actually need to be loaded as part of the onchain proof. Hinting allows the program, when generating a proof offchain, to instruct the VM what data it is interested in. The VM can choose to execute the requested hint at any time: either locally (for standard requests), or in a modular form by redirecting the hint to tooling that may come with the VM program. Hints do not have to be executed directly: they may first just be logged to show the intents of the program, and the latest hint may be buffered for lazy execution, or dropped entirely when in read-only mode (like onchain). When the pre-image oracle serves a request, and the request cannot be served from an existing collection of pre-images (e.g. a local pre-image cache) then the VM can execute the hint to retrieve the missing pre-image(s). It is the responsibility of the program to provide sufficient hinting for every pre-image request. Some hints may have to be repeated: the VM only has to execute the last hint when handling a missing pre-image. Note that hints may produce multiple pre-images: e.g. a hint for an ethereum block with transaction list may prepare pre-images for the header, each of the transactions, and the intermediate merkle-nodes that form the transactions-list Merkle Patricia Trie. Hinting is implemented with a request-acknowledgement wire-protocol over a blocking two-way stream: := := := big-endian uint32 # length of \n := byte sequence\n := 1-byte zero value The ack informs the client that the hint has been processed. Servers may respond to hints and pre-image (see below) requests asynchronously as they are on separate streams. To avoid requesting pre-images that are not yet fetched, clients should request the pre-image only after it has observed the hint acknowledgement.","breadcrumbs":"OP Stack Protocol » Fault Proof » Hinting","id":"170","title":"Hinting"},"171":{"body":"Pre-images are communicated with a minimal wire-protocol over a blocking two-way stream. This protocol can be implemented with blocking read/write syscalls. :=
deploy
PayloadAttributesV3: { @@ -283,7 +238,7 @@ eip1559Params encoding +eip1559Params encoding NameTypeByte Offset denominatoru32 (big-endian)[0, 4) elasticityu32 (big-endian)[4, 8) @@ -303,19 +258,19 @@ Execution -Rationale +Rationale This type is made available in the payload attributes to allow the block builder to dynamically control the EIP-1559 parameters of the chain. As described in the derivation - AttributesBuilder section, the derivation pipeline must populate this field from the SystemConfig during payload building, similar to how it must reference the SystemConfig for the gasLimit field. -eip1559Params in Header +eip1559Params in Header Upon Holocene activation, the L2 block header's nonce field will consist of the 8-byte eip1559Params value. -Header Validity Rules +Header Validity Rules Prior to Holocene activation, the L2 block header's nonce field is valid iff it is equal to u64(0). After Holocene activation, The L2 block header's nonce field is valid iff it is non-zero. -Encoding +Encoding The encoding of the eip1559Params value is described in eip1559Params encoding. -Rationale +Rationale By chosing to put the eip1559Params in the PayloadAttributes rather than in the L1 block info transaction, the EIP-1559 parameters for the chain are not available within history. This would place a burden on performing historical execution, as L1 would have to be consulted for fetching the values from the SystemConfig contract. diff --git a/protocol/holocene/overview.html b/protocol/holocene/overview.html index 0ce159035..1714698a1 100644 --- a/protocol/holocene/overview.html +++ b/protocol/holocene/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -199,10 +199,9 @@ Smart Contracts -This document is not finalized and should be considered experimental. Execution Layer -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters Consensus Layer @@ -210,8 +209,7 @@ Consensus Lay Smart Contracts -Predeploys -Configurability +System Config diff --git a/protocol/holocene/predeploys.html b/protocol/holocene/predeploys.html index 3c4f9c31d..3c6067ec3 100644 --- a/protocol/holocene/predeploys.html +++ b/protocol/holocene/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -189,209 +189,7 @@ OP Stack Specification -Overview - - -Table of Contents - -Constants -Predeploys - -L1Block - -Storage -Interface - -setHolocene -setConfig -baseFeeVaultConfig -sequencerFeeVaultConfig -l1FeeVaultConfig -l1CrossDomainMessenger -l1StandardBridge -l1ERC721Bridge -remoteChainId - - - - -FeeVault - -Interface - -config - - - - -L2CrossDomainMessenger - -Interface - - -L2ERC721Bridge - -Interface - - -L2StandardBridge - -Interface - - -OptimismMintableERC721Factory - - -Security Considerations - -GovernanceToken - - - - -This upgrade enables a deterministic L2 genesis state by moving all network -specific configuration out of the initial L2 genesis state. All network specific -configuration is sourced from deposit transactions during the initialization -of the SystemConfig. -Constants -NameValueDefinition -ConfigTypeuint8An enum representing the type of config being set -WithdrawalNetworkuint8(0) or uint8(1)0 means withdraw to L1, 1 means withdraw to L2 -RECIPIENTaddressThe account that will receive funds sent out of the FeeVault -MIN_WITHDRAWAL_AMOUNTuint256The minimum amount of native asset held in the FeeVault before withdrawal is authorized -Fee Vault Configbytes32bytes32((WithdrawalNetwork << 248) || uint256(uint88(MIN_WITHDRAWAL_AMOUNT)) || uint256(uint160(RECIPIENT))) -BASE_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.basefeevaultconfig")) - 1)The Fee Vault Config for the BaseFeeVault -L1_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.l1feevaultconfig")) - 1)The Fee Vault Config for the L1FeeVault -SEQUENCER_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.sequencerfeevaultconfig")) - 1)The Fee Vault Config for the SequencerFeeVault -L1_CROSS_DOMAIN_MESSENGER_ADDRESSbytes32(uint256(keccak256("opstack.l1crossdomainmessengeraddress")) - 1)abi.encode(address(L1CrossDomainMessengerProxy)) -L1_ERC_721_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1erc721bridgeaddress")) - 1)abi.encode(address(L1ERC721BridgeProxy)) -L1_STANDARD_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1standardbridgeaddress")) - 1)abi.encode(address(L1StandardBridgeProxy)) -REMOTE_CHAIN_IDbytes32(uint256(keccak256("opstack.remotechainid")) - 1)Chain ID of the remote chain - - -Predeploys -All network specific configuration is moved to a single contract, the L1Block predeploy. -All predeploys make calls to the L1Block contract to fetch network specific configuration -rather than reading it from local state. -graph LR - subgraph L1 - SystemConfig -- "setConfig(uint8,bytes)" --> OptimismPortal - end - subgraph L2 - L1Block - BaseFeeVault -- "baseFeeVaultConfig()(address,uint256,uint8)" --> L1Block - SequencerFeeVault -- "sequencerFeeVaultConfig()(address,uint256,uint8)" --> L1Block - L1FeeVault -- "l1FeeVaultConfig()(address,uint256,uint8)" --> L1Block - L2CrossDomainMessenger -- "l1CrossDomainMessenger()(address)" --> L1Block - L2StandardBridge -- "l1StandardBridge()(address)" --> L1Block - L2ERC721Bridge -- "l1ERC721Bridge()(address)" --> L1Block - OptimismMintableERC721Factory -- "remoteChainId()(uint256)" --> L1Block - end - OptimismPortal -- "setConfig(uint8,bytes)" --> L1Block - -L1Block -Storage -The following storage slots are defined: - -BASE_FEE_VAULT_CONFIG -L1_FEE_VAULT_CONFIG -SEQUENCER_FEE_VAULT_CONFIG -L1_CROSS_DOMAIN_MESSENGER_ADDRESS -L1_ERC_721_BRIDGE_ADDRESS -L1_STANDARD_BRIDGE_ADDRESS -REMOTE_CHAIN_ID - -Each slot MUST have a defined ConfigType that authorizes the setting of the storage slot -via a deposit transaction from the DEPOSITOR_ACCOUNT. -Interface -setHolocene -This function is meant to be called once on the activation block of the holocene network upgrade. -It MUST only be callable by the DEPOSITOR_ACCOUNT once. When it is called, it MUST call -call each getter for the network specific config and set the returndata into storage. -setConfig -This function MUST only be callable by the DEPOSITOR_ACCOUNT. It modifies the storage directly -of the L1Block contract. It MUST handle all defined ConfigTypes. To ensure a simple ABI, the -bytes value MUST be abi decoded based on the ConfigType. -function setConfig(ConfigType,bytes) - -Note that ConfigType is an enum which is an alias for a uint8. -baseFeeVaultConfig -This function MUST be called by the BaseFeeVault to fetch network specific configuration. -function baseFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -sequencerFeeVaultConfig -This function MUST be called by the SequencerFeeVault to fetch network specific configuration. -function sequencerFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1FeeVaultConfig -This function MUST be called by the L1FeeVault to fetch network specific configuration. -function l1FeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1CrossDomainMessenger -This function MUST be called by the L2CrossDomainMessenger to fetch the address of the L1CrossDomainMessenger. -function l1CrossDomainMessenger()(address) - -l1StandardBridge -This function MUST be called by the L2StandardBridge to fetch the address of the L2CrossDomainMessenger. -function l1StandardBridge()(address) - -l1ERC721Bridge -This function MUST be called by the L2ERC721Bridge to fetch the address of the L1ERC721Bridge. -function l1ERC721Bridge()(address) - -remoteChainId -This function MUST be called by the OptimismMintableERC721Factory to fetch the chain id of the remote chain. -For an L2, this is the L1 chain id. -function remoteChainId()(uint256) - -FeeVault -The following changes apply to each of the BaseFeeVault, the L1FeeVault and the SequencerFeeVault. -Interface -The following functions are updated to read from the L1Block contract: - -recipient()(address) -withdrawalNetwork()(WithdrawalNetwork) -minWithdrawalAmount()(uint256) -withdraw() - -NameCall -BaseFeeVaultL1Block.baseFeeVaultConfig() -SequencerFeeVaultL1Block.sequencerFeeVaultConfig() -L1FeeVaultL1Block.l1FeeVaultConfig() - - -config -A new function is added to fetch the full Fee Vault Config. -function config()(address,uint256,WithdrawalNetwork) - -L2CrossDomainMessenger -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1CrossDomainMessenger(): - -otherMessenger()(address) -OTHER_MESSENGER()(address) - -L2ERC721Bridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1ERC721Bridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -L2StandardBridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1StandardBridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -OptimismMintableERC721Factory -The chain id is no longer read from storage but instead is read from the L1Block contract by calling -L1Block.remoteChainId() -Security Considerations -GovernanceToken -The predeploy defined by GovernanceToken should be an empty account until it is defined by -a future hardfork. +Predeploys @@ -401,7 +199,7 @@ GovernanceTok - + @@ -415,7 +213,7 @@ GovernanceTok - + diff --git a/protocol/holocene/configurability.html b/protocol/holocene/system-config.html similarity index 72% rename from protocol/holocene/configurability.html rename to protocol/holocene/system-config.html index 985283b56..0df792e3e 100644 --- a/protocol/holocene/configurability.html +++ b/protocol/holocene/system-config.html @@ -3,7 +3,7 @@ - Configurability - OP Stack Specification + System Config - OP Stack Specification @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -159,7 +159,7 @@ OP Stack Specification - + @@ -189,18 +189,12 @@ OP Stack Specification -Configurability +System Config Table of Contents -Overview -Constants - -ConfigType - - -SystemConfig +Overview ConfigUpdate Initialization @@ -214,22 +208,6 @@ Configurabili eip1559Denominator -Fee Vault Config - -setBaseFeeVaultConfig -setL1FeeVaultConfig -setSequencerFeeVaultConfig - - - - - - -OptimismPortal - -Interface - -setConfig @@ -237,23 +215,7 @@ Configurabili Overview -The SystemConfig and OptimismPortal are updated with a new flow for chain -configurability. -Constants -ConfigType -The ConfigType enum represents configuration that can be modified. -NameValueDescription -SET_GAS_PAYING_TOKENuint8(0)Modifies the gas paying token for the chain -SET_BASE_FEE_VAULT_CONFIGuint8(1)Sets the Fee Vault Config for the BaseFeeVault -SET_L1_FEE_VAULT_CONFIGuint8(2)Sets the Fee Vault Config for the L1FeeVault -SET_SEQUENCER_FEE_VAULT_CONFIGuint8(3)Sets the Fee Vault Config for the SequencerFeeVault -SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESSuint8(4)Sets the L1CrossDomainMessenger address -SET_L1_ERC_721_BRIDGE_ADDRESSuint8(5)Sets the L1ERC721Bridge address -SET_L1_STANDARD_BRIDGE_ADDRESSuint8(6)Sets the L1StandardBridge address -SET_REMOTE_CHAIN_IDuint8(7)Sets the chain id of the base chain - - -SystemConfig +The SystemConfig is updated to allow for dynamic EIP-1559 parameters. ConfigUpdate The following ConfigUpdate event is defined where the CONFIG_VERSION is uint256(0): NameValueDefinitionUsage @@ -272,16 +234,7 @@ Initialization< emit ConfigUpdate.GAS_LIMIT emit ConfigUpdate.UNSAFE_BLOCK_SIGNER emit ConfigUpdate.EIP_1559_PARAMS -setConfig(SET_GAS_PAYING_TOKEN) -setConfig(SET_BASE_FEE_VAULT_CONFIG) -setConfig(SET_L1_FEE_VAULT_CONFIG) -setConfig(SET_SEQUENCER_FEE_VAULT_CONFIG) -setConfig(SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESS) -setConfig(SET_L1_ERC_721_BRIDGE_ADDRESS) -setConfig(SET_L1_STANDARD_BRIDGE_ADDRESS) -setConfig(SET_REMOTE_CHAIN_ID) -These actions MAY only be triggered if there is a diff to the value. Modifying EIP-1559 Parameters A new SystemConfig UpdateType is introduced that enables the modification of EIP-1559 parameters. This allows for the chain @@ -302,39 +255,6 @@ e This function returns the currently configured EIP-1559 denominator. function eip1559Denominator()(uint64) -Fee Vault Config -For each FeeVault, there is a setter for its config. The arguments to the setter include -the RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork. -Each of these functions should be public and only callable by the chain governor. -Each function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType. -setBaseFeeVaultConfig -function setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork) - -setL1FeeVaultConfig -function setL1FeeVaultConfig(address,uint256,WithdrawalNetwork) - -setSequencerFeeVaultConfig -function setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork) - -OptimismPortal -The OptimismPortal is updated to emit a special system TransactionDeposited event. -Interface -setConfig -The setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig -is the single source of truth for chain operator ownership. -function setConfig(ConfigType,bytes) - -This function emits a TransactionDeposited event. -event TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData); - -The following fields are included: - -from is the DEPOSITOR_ACCOUNT -to is Predeploys.L1Block -version is uint256(0) -opaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit -is 200_000, isCreation is false and the data is abi.encodeCall(L1Block.setConfig, (_type, _value)) - diff --git a/protocol/messengers.html b/protocol/messengers.html index 5719b0eac..b0c6745a4 100644 --- a/protocol/messengers.html +++ b/protocol/messengers.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/overview.html b/protocol/overview.html index 19a171b6b..8d974911d 100644 --- a/protocol/overview.html +++ b/protocol/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/precompiles.html b/protocol/precompiles.html index 2636bcded..591225781 100644 --- a/protocol/precompiles.html +++ b/protocol/precompiles.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/predeploys.html b/protocol/predeploys.html index f69344d63..18f80ecc9 100644 --- a/protocol/predeploys.html +++ b/protocol/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/preinstalls.html b/protocol/preinstalls.html index a3e678702..de25cd1f4 100644 --- a/protocol/preinstalls.html +++ b/protocol/preinstalls.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/proposals.html b/protocol/proposals.html index 4356aed7b..c7e27aba0 100644 --- a/protocol/proposals.html +++ b/protocol/proposals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/regolith/overview.html b/protocol/regolith/overview.html index 25fb28a59..735c8d392 100644 --- a/protocol/regolith/overview.html +++ b/protocol/regolith/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node-p2p.html b/protocol/rollup-node-p2p.html index 6b7b877ad..f733fce32 100644 --- a/protocol/rollup-node-p2p.html +++ b/protocol/rollup-node-p2p.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node.html b/protocol/rollup-node.html index 7b2194855..74e7465df 100644 --- a/protocol/rollup-node.html +++ b/protocol/rollup-node.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/safe-extensions.html b/protocol/safe-extensions.html index c13615619..4601198ba 100644 --- a/protocol/safe-extensions.html +++ b/protocol/safe-extensions.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/stage-1.html b/protocol/stage-1.html index d28f06461..2659aa26c 100644 --- a/protocol/stage-1.html +++ b/protocol/stage-1.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-configuration.html b/protocol/superchain-configuration.html index ee7a3f560..6796bb40e 100644 --- a/protocol/superchain-configuration.html +++ b/protocol/superchain-configuration.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-upgrades.html b/protocol/superchain-upgrades.html index e9ac90b28..aad45a9b2 100644 --- a/protocol/superchain-upgrades.html +++ b/protocol/superchain-upgrades.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/system-config.html b/protocol/system-config.html index afbdefd92..d5fe843f1 100644 --- a/protocol/system-config.html +++ b/protocol/system-config.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/withdrawals.html b/protocol/withdrawals.html index e390c5450..8596661a9 100644 --- a/protocol/withdrawals.html +++ b/protocol/withdrawals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/root.html b/root.html index 20d712d67..bd978d50b 100644 --- a/root.html +++ b/root.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/searchindex.js b/searchindex.js index 371b06267..623744500 100644 --- a/searchindex.js +++ b/searchindex.js @@ -1 +1 @@ -Object.assign(window.search, {"doc_urls":["root.html#op-stack-specification","root.html#about-optimism","root.html#about-the-op-stack","root.html#site-navigation","background.html#background","background.html#overview","background.html#foundations","background.html#ethereum-scalability","background.html#optimistic-rollups","background.html#evm-equivalence","background.html#protocol-guarantees","background.html#liveness","background.html#validity","background.html#availability","background.html#network-participants","background.html#users","background.html#sequencers","background.html#verifiers","background.html#key-interaction-diagrams","background.html#depositing-and-sending-transactions","background.html#withdrawing","background.html#next-steps","protocol/overview.html#optimism-overview","protocol/overview.html#architecture-design-goals","protocol/overview.html#architecture-overview","protocol/overview.html#core-l1-smart-contracts","protocol/overview.html#core-l2-smart-contracts","protocol/overview.html#smart-contract-proxies","protocol/overview.html#l2-node-components","protocol/overview.html#transactionblock-propagation","protocol/overview.html#key-interactions-in-depth","protocol/overview.html#deposits","protocol/overview.html#block-derivation","protocol/overview.html#engine-api","protocol/bridges.html#standard-bridges","protocol/bridges.html#overview","protocol/bridges.html#token-depositing","protocol/bridges.html#upgradability","protocol/messengers.html#cross-domain-messengers","protocol/messengers.html#overview","protocol/messengers.html#message-passing","protocol/messengers.html#upgradability","protocol/messengers.html#message-versioning","protocol/messengers.html#message-version-0","protocol/messengers.html#message-version-1","protocol/messengers.html#backwards-compatibility-notes","protocol/deposits.html#deposits","protocol/deposits.html#overview","protocol/deposits.html#the-deposited-transaction-type","protocol/deposits.html#source-hash-computation","protocol/deposits.html#kinds-of-deposited-transactions","protocol/deposits.html#validation-and-authorization-of-deposited-transactions","protocol/deposits.html#execution","protocol/deposits.html#deposit-receipt","protocol/deposits.html#l1-attributes-deposited-transaction","protocol/deposits.html#l1-attributes-deposited-transaction-calldata","protocol/deposits.html#special-accounts-on-l2","protocol/deposits.html#l1-attributes-depositor-account","protocol/deposits.html#l1-attributes-predeployed-contract","protocol/deposits.html#user-deposited-transactions","protocol/deposits.html#deposit-contract","protocol/withdrawals.html#withdrawals","protocol/withdrawals.html#overview","protocol/withdrawals.html#withdrawal-flow","protocol/withdrawals.html#on-l2","protocol/withdrawals.html#on-l1","protocol/withdrawals.html#the-l2tol1messagepasser-contract","protocol/withdrawals.html#addresses-are-not-aliased-on-withdrawals","protocol/withdrawals.html#the-optimism-portal-contract","protocol/withdrawals.html#withdrawal-verification-and-finalization","protocol/withdrawals.html#security-considerations","protocol/withdrawals.html#key-properties-of-withdrawal-verification","protocol/withdrawals.html#handling-successfully-verified-messages-that-fail-when-relayed","protocol/withdrawals.html#optimismportal-can-send-arbitrary-messages-on-l1","protocol/guaranteed-gas-market.html#guaranteed-gas-fee-market","protocol/guaranteed-gas-market.html#overview","protocol/guaranteed-gas-market.html#gas-stipend","protocol/guaranteed-gas-market.html#default-values","protocol/guaranteed-gas-market.html#limiting-guaranteed-gas","protocol/guaranteed-gas-market.html#rationale-for-burning-l1-gas","protocol/guaranteed-gas-market.html#on-preventing-griefing-attacks","protocol/proposals.html#l2-output-root-proposals-specification","protocol/proposals.html#overview","protocol/proposals.html#proposing-l2-output-commitments","protocol/proposals.html#l2outputoracle-v100","protocol/proposals.html#l2-output-commitment-construction","protocol/proposals.html#l2-output-oracle-smart-contract","protocol/proposals.html#configuration","protocol/proposals.html#security-considerations","protocol/proposals.html#l1-reorgs","protocol/exec-engine.html#l2-execution-engine","protocol/exec-engine.html#1559-parameters","protocol/exec-engine.html#deposited-transaction-processing","protocol/exec-engine.html#deposited-transaction-boundaries","protocol/exec-engine.html#fees","protocol/exec-engine.html#fee-vaults","protocol/exec-engine.html#priority-fees-sequencer-fee-vault","protocol/exec-engine.html#base-fees-base-fee-vault","protocol/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/exec-engine.html#engine-api","protocol/exec-engine.html#engine_forkchoiceupdatedv2","protocol/exec-engine.html#engine_forkchoiceupdatedv3","protocol/exec-engine.html#engine_newpayloadv2","protocol/exec-engine.html#engine_newpayloadv3","protocol/exec-engine.html#engine_getpayloadv2","protocol/exec-engine.html#engine_getpayloadv3","protocol/exec-engine.html#engine_signalsuperchainv1","protocol/exec-engine.html#networking","protocol/exec-engine.html#sync","protocol/exec-engine.html#happy-path-sync","protocol/exec-engine.html#worst-case-sync","protocol/exec-engine.html#ecotone-disable-blob-transactions","protocol/exec-engine.html#ecotone-beacon-block-root","protocol/exec-engine.html#p2p-modifications","protocol/rollup-node.html#rollup-node-specification","protocol/rollup-node.html#overview","protocol/rollup-node.html#driver","protocol/rollup-node.html#derivation","protocol/rollup-node.html#l2-output-rpc-method","protocol/rollup-node.html#structures","protocol/rollup-node.html#output-method-api","protocol/rollup-node.html#protocol-version-tracking","protocol/rollup-node-p2p.html#rollup-node-p2p-interface","protocol/rollup-node-p2p.html#overview","protocol/rollup-node-p2p.html#p2p-configuration","protocol/rollup-node-p2p.html#identification","protocol/rollup-node-p2p.html#discv5","protocol/rollup-node-p2p.html#libp2p","protocol/rollup-node-p2p.html#gossip-topics","protocol/rollup-node-p2p.html#blocksv1","protocol/rollup-node-p2p.html#blocksv2","protocol/rollup-node-p2p.html#blocksv3","protocol/rollup-node-p2p.html#block-encoding","protocol/rollup-node-p2p.html#block-signatures","protocol/rollup-node-p2p.html#block-validation","protocol/rollup-node-p2p.html#req-resp","protocol/rollup-node-p2p.html#payload_by_number","protocol/derivation.html#l2-chain-derivation-specification","protocol/derivation.html#overview","protocol/derivation.html#eager-block-derivation","protocol/derivation.html#protocol-parameters","protocol/derivation.html#batch-submission","protocol/derivation.html#sequencing--batch-submission-overview","protocol/derivation.html#batch-submission-wire-format","protocol/derivation.html#batcher-transaction-format","protocol/derivation.html#frame-format","protocol/derivation.html#channel-format","protocol/derivation.html#batch-format","protocol/derivation.html#architecture","protocol/derivation.html#l2-chain-derivation-pipeline","protocol/derivation.html#l1-traversal","protocol/derivation.html#l1-retrieval","protocol/derivation.html#frame-queue","protocol/derivation.html#channel-bank","protocol/derivation.html#channel-reader-batch-decoding","protocol/derivation.html#batch-queue","protocol/derivation.html#payload-attributes-derivation","protocol/derivation.html#engine-queue","protocol/derivation.html#resetting-the-pipeline","protocol/derivation.html#deriving-payload-attributes","protocol/derivation.html#deriving-the-transaction-list","protocol/derivation.html#network-upgrade-automation-transactions","protocol/derivation.html#building-individual-payload-attributes","protocol/batcher.html#batch-submitter","protocol/batcher.html#overview","fault-proof/index.html#fault-proof","fault-proof/index.html#overview","fault-proof/index.html#pre-image-oracle","fault-proof/index.html#pre-image-key-types","fault-proof/index.html#bootstrapping","fault-proof/index.html#hinting","fault-proof/index.html#pre-image-communication","fault-proof/index.html#fault-proof-program","fault-proof/index.html#prologue","fault-proof/index.html#main-content","fault-proof/index.html#epilogue","fault-proof/index.html#pre-image-hinting-routes","fault-proof/index.html#precompile-accelerators","fault-proof/index.html#fault-proof-vm","fault-proof/index.html#fault-proof-interactive-dispute-game","fault-proof/cannon-fault-proof-vm.html#cannon-fault-proof-virtual-machine","fault-proof/cannon-fault-proof-vm.html#overview","fault-proof/cannon-fault-proof-vm.html#state","fault-proof/cannon-fault-proof-vm.html#state-hash","fault-proof/cannon-fault-proof-vm.html#memory","fault-proof/cannon-fault-proof-vm.html#heap","fault-proof/cannon-fault-proof-vm.html#delay-slots","fault-proof/cannon-fault-proof-vm.html#syscalls","fault-proof/cannon-fault-proof-vm.html#io","fault-proof/cannon-fault-proof-vm.html#standard-streams","fault-proof/cannon-fault-proof-vm.html#hint-communication","fault-proof/cannon-fault-proof-vm.html#pre-image-communication","fault-proof/cannon-fault-proof-vm.html#exceptions","fault-proof/cannon-fault-proof-vm.html#security-model","fault-proof/cannon-fault-proof-vm.html#compiler-correctness","fault-proof/cannon-fault-proof-vm.html#compiler-assumptions","fault-proof/stage-one/index.html#stage-one-decentralization","fault-proof/stage-one/dispute-game-interface.html#dispute-game-interface","fault-proof/stage-one/dispute-game-interface.html#overview","fault-proof/stage-one/dispute-game-interface.html#types","fault-proof/stage-one/dispute-game-interface.html#disputegamefactory-interface","fault-proof/stage-one/dispute-game-interface.html#disputegame-interface","fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game","fault-proof/stage-one/fault-dispute-game.html#overview","fault-proof/stage-one/fault-dispute-game.html#definitions","fault-proof/stage-one/fault-dispute-game.html#virtual-machine-vm","fault-proof/stage-one/fault-dispute-game.html#preimageoracle","fault-proof/stage-one/fault-dispute-game.html#execution-trace","fault-proof/stage-one/fault-dispute-game.html#claims","fault-proof/stage-one/fault-dispute-game.html#anchor-state","fault-proof/stage-one/fault-dispute-game.html#anchor-state-registry","fault-proof/stage-one/fault-dispute-game.html#dag","fault-proof/stage-one/fault-dispute-game.html#subgame","fault-proof/stage-one/fault-dispute-game.html#game-tree","fault-proof/stage-one/fault-dispute-game.html#position","fault-proof/stage-one/fault-dispute-game.html#max_clock_duration","fault-proof/stage-one/fault-dispute-game.html#clock_extension","fault-proof/stage-one/fault-dispute-game.html#freeloader-claims","fault-proof/stage-one/fault-dispute-game.html#core-game-mechanics","fault-proof/stage-one/fault-dispute-game.html#actors","fault-proof/stage-one/fault-dispute-game.html#moves","fault-proof/stage-one/fault-dispute-game.html#l2-block-number-challenge","fault-proof/stage-one/fault-dispute-game.html#step","fault-proof/stage-one/fault-dispute-game.html#step-types","fault-proof/stage-one/fault-dispute-game.html#preimageoracle-interaction","fault-proof/stage-one/fault-dispute-game.html#team-dynamics","fault-proof/stage-one/fault-dispute-game.html#game-clock","fault-proof/stage-one/fault-dispute-game.html#resolution","fault-proof/stage-one/fault-dispute-game.html#finalization","fault-proof/stage-one/honest-challenger-fdg.html#honest-challenger-fault-dispute-game","fault-proof/stage-one/honest-challenger-fdg.html#overview","fault-proof/stage-one/honest-challenger-fdg.html#invariants","fault-proof/stage-one/honest-challenger-fdg.html#fault-dispute-game-responses","fault-proof/stage-one/honest-challenger-fdg.html#moves","fault-proof/stage-one/honest-challenger-fdg.html#steps","fault-proof/stage-one/honest-challenger-fdg.html#timeliness","fault-proof/stage-one/honest-challenger-fdg.html#resolution","fault-proof/stage-one/bond-incentives.html#bond-incentives","fault-proof/stage-one/bond-incentives.html#overview","fault-proof/stage-one/bond-incentives.html#moves","fault-proof/stage-one/bond-incentives.html#subgame-resolution","fault-proof/stage-one/bond-incentives.html#leftmost-claim-incentives","fault-proof/stage-one/bond-incentives.html#fault-proof-mainnet-incentives","fault-proof/stage-one/bond-incentives.html#authenticated-roles","fault-proof/stage-one/bond-incentives.html#base-fee-assumption","fault-proof/stage-one/bond-incentives.html#bond-scaling","fault-proof/stage-one/bond-incentives.html#required-bond-formula","fault-proof/stage-one/bond-incentives.html#other-incentives","fault-proof/stage-one/bond-incentives.html#delayedweth","fault-proof/stage-one/bridge-integration.html#bridge-integration","fault-proof/stage-one/bridge-integration.html#overview","fault-proof/stage-one/bridge-integration.html#legacy-semantics","fault-proof/stage-one/bridge-integration.html#fpac-optimismportal-mods-specification","fault-proof/stage-one/bridge-integration.html#roles---optimismportal","fault-proof/stage-one/bridge-integration.html#new-deployconfig-variables","fault-proof/stage-one/bridge-integration.html#data-structures","fault-proof/stage-one/bridge-integration.html#state-layout","fault-proof/stage-one/bridge-integration.html#provewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#finalizewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#air-gap","fault-proof/stage-one/bridge-integration.html#proxy-upgrade","fault-proof/stage-one/bridge-integration.html#permissioned-faultdisputegame","fault-proof/stage-one/bridge-integration.html#roles---permissioneddisputegame","fault-proof/stage-one/bridge-integration.html#modifications","protocol/precompiles.html#precompiles","protocol/precompiles.html#overview","protocol/precompiles.html#p256verify","protocol/predeploys.html#predeploys","protocol/predeploys.html#overview","protocol/predeploys.html#legacymessagepasser","protocol/predeploys.html#l2tol1messagepasser","protocol/predeploys.html#deployerwhitelist","protocol/predeploys.html#legacyerc20eth","protocol/predeploys.html#weth9","protocol/predeploys.html#l2crossdomainmessenger","protocol/predeploys.html#l2standardbridge","protocol/predeploys.html#l1blocknumber","protocol/predeploys.html#gaspriceoracle","protocol/predeploys.html#l1block","protocol/predeploys.html#proxyadmin","protocol/predeploys.html#sequencerfeevault","protocol/predeploys.html#optimismmintableerc20factory","protocol/predeploys.html#optimismmintableerc721factory","protocol/predeploys.html#basefeevault","protocol/predeploys.html#l1feevault","protocol/predeploys.html#schemaregistry","protocol/predeploys.html#eas","protocol/predeploys.html#beacon-block-root","protocol/preinstalls.html#preinstalls","protocol/preinstalls.html#overview","protocol/preinstalls.html#safe","protocol/preinstalls.html#safel2","protocol/preinstalls.html#multisend","protocol/preinstalls.html#multisendcallonly","protocol/preinstalls.html#safesingletonfactory","protocol/preinstalls.html#multicall3","protocol/preinstalls.html#create2deployer","protocol/preinstalls.html#createx","protocol/preinstalls.html#arachnids-deterministic-deployment-proxy","protocol/preinstalls.html#permit2","protocol/preinstalls.html#erc-4337-v060-entrypoint","protocol/preinstalls.html#erc-4337-v060-sendercreator","protocol/preinstalls.html#erc-4337-v070-entrypoint","protocol/preinstalls.html#erc-4337-v070-sendercreator","protocol/superchain-configuration.html#superchain-configuration","protocol/superchain-configuration.html#overview","protocol/superchain-configuration.html#configurable-values","protocol/superchain-configuration.html#configuration-data-flow","protocol/superchain-configuration.html#pausability","protocol/superchain-upgrades.html#superchain-upgrades","protocol/superchain-upgrades.html#overview","protocol/superchain-upgrades.html#protocol-version","protocol/superchain-upgrades.html#protocol-version-format","protocol/superchain-upgrades.html#protocol-version-exposure","protocol/superchain-upgrades.html#superchain-target","protocol/superchain-upgrades.html#superchain-version-signaling","protocol/superchain-upgrades.html#protocolversions-l1-contract","protocol/superchain-upgrades.html#activation-rules","protocol/superchain-upgrades.html#l2-block-number-based-activation-deprecated","protocol/superchain-upgrades.html#l2-block-timestamp-based-activation","protocol/superchain-upgrades.html#op-stack-protocol-versions","protocol/superchain-upgrades.html#post-bedrock-network-upgrades","protocol/superchain-upgrades.html#activation-timestamps","protocol/system-config.html#system-config","protocol/system-config.html#overview","protocol/system-config.html#system-config-contents-version-0","protocol/system-config.html#batcherhash-bytes32","protocol/system-config.html#scalars","protocol/system-config.html#gaslimit-uint64","protocol/system-config.html#unsafeblocksigner-address","protocol/system-config.html#writing-the-system-config","protocol/system-config.html#reading-the-system-config","protocol/configurability.html#op-stack-configurability","protocol/configurability.html#consensus-parameters","protocol/configurability.html#batch-inbox-address","protocol/configurability.html#batcher-hash","protocol/configurability.html#chain-id","protocol/configurability.html#proof-maturity-delay","protocol/configurability.html#dispute-game-finality","protocol/configurability.html#respected-game-type","protocol/configurability.html#fault-game-max-depth","protocol/configurability.html#fault-game-split-depth","protocol/configurability.html#max-game-clock-duration","protocol/configurability.html#game-clock-extension","protocol/configurability.html#bond-withdrawal-delay","protocol/configurability.html#minimum-large-preimage-proposal-size","protocol/configurability.html#large-preimage-proposal-challenge-period","protocol/configurability.html#fault-game-absolute-prestate","protocol/configurability.html#fault-game-genesis-block","protocol/configurability.html#fault-game-genesis-output-root","protocol/configurability.html#fee-scalar","protocol/configurability.html#gas-limit","protocol/configurability.html#genesis-state","protocol/configurability.html#l2-block-time","protocol/configurability.html#resource-config","protocol/configurability.html#sequencing-window-size","protocol/configurability.html#start-block","protocol/configurability.html#superchain-target","protocol/configurability.html#governance-token","protocol/configurability.html#resource-config-1","protocol/configurability.html#policy-parameters","protocol/configurability.html#data-availability-type","protocol/configurability.html#batch-submission-frequency","protocol/configurability.html#output-frequency","protocol/configurability.html#admin-roles","protocol/configurability.html#l1-proxy-admin","protocol/configurability.html#l1-proxyadmin-owner","protocol/configurability.html#l2-proxy-admin","protocol/configurability.html#l2-proxyadmin-owner","protocol/configurability.html#system-config-owner","protocol/configurability.html#service-roles","protocol/configurability.html#batch-submitter-address","protocol/configurability.html#challenger-address","protocol/configurability.html#guardian-address","protocol/configurability.html#proposer-address","protocol/configurability.html#sequencer-p2p--unsafe-head-signer","protocol/safe-extensions.html#safe-contract-extensions","protocol/safe-extensions.html#guardian-safe","protocol/safe-extensions.html#deputy-guardian-module","protocol/safe-extensions.html#deputy-guardian-module-security-properties","protocol/safe-extensions.html#security-council-liveness-checking-extensions","protocol/safe-extensions.html#the-liveness-guard","protocol/safe-extensions.html#the-liveness-module","protocol/safe-extensions.html#owner-removal-call-flow","protocol/safe-extensions.html#shutdown","protocol/safe-extensions.html#liveness-security-properties","protocol/safe-extensions.html#interdependency-between-the-liveness-guard-and-liveness-module","protocol/safe-extensions.html#operational-considerations","protocol/safe-extensions.html#manual-validation-of-new-owner-liveness","protocol/safe-extensions.html#deploying-the-liveness-checking-system","protocol/safe-extensions.html#modifying-the-liveness-checking-system","protocol/stage-1.html#stage-1-roles-and-requirements","protocol/stage-1.html#overview","protocol/stage-1.html#permissionless-fault-proofs","protocol/stage-1.html#roles-for-stage-1","protocol/stage-1.html#configuration-of-safes","protocol/stage-1.html#ownership-model-diagram","protocol/regolith/overview.html#regolith","protocol/regolith/overview.html#overview","protocol/canyon/overview.html#canyon","protocol/canyon/overview.html#execution-layer","protocol/canyon/overview.html#consensus-layer","protocol/delta/overview.html#delta","protocol/delta/overview.html#consensus-layer","protocol/delta/span-batches.html#span-batches","protocol/delta/span-batches.html#introduction","protocol/delta/span-batches.html#span-batch-format","protocol/delta/span-batches.html#span-batch-size-limits","protocol/delta/span-batches.html#future-batch-format-extension","protocol/delta/span-batches.html#span-batch-activation-rule","protocol/delta/span-batches.html#optimization-strategies","protocol/delta/span-batches.html#truncating-information-and-storing-only-necessary-data","protocol/delta/span-batches.html#tx_data_headers-removal-from-initial-specs","protocol/delta/span-batches.html#chain-id-removal-from-initial-specs","protocol/delta/span-batches.html#reorganization-of-constant-length-transaction-fields","protocol/delta/span-batches.html#rlp-encoding-for-only-variable-length-fields","protocol/delta/span-batches.html#store-y_parity-and-protected_bit-instead-of-v","protocol/delta/span-batches.html#adjust-txs-data-layout-for-better-compression","protocol/delta/span-batches.html#fee_recipients-encoding-scheme","protocol/delta/span-batches.html#how-derivation-works-with-span-batches","protocol/delta/span-batches.html#integration","protocol/delta/span-batches.html#channel-reader-batch-decoding","protocol/delta/span-batches.html#batch-queue","protocol/delta/span-batches.html#batcher","protocol/ecotone/overview.html#ecotone-network-upgrade","protocol/ecotone/overview.html#execution-layer","protocol/ecotone/overview.html#consensus-layer","protocol/ecotone/derivation.html#derivation","protocol/ecotone/derivation.html#ecotone-blob-retrieval","protocol/ecotone/derivation.html#blob-encoding","protocol/ecotone/l1-attributes.html#ecotone-l1-attributes","protocol/ecotone/l1-attributes.html#overview","protocol/ecotone/l1-attributes.html#l1-attributes-predeployed-contract","protocol/ecotone/l1-attributes.html#ecotone-l1block-upgrade","protocol/fjord/overview.html#fjord-network-upgrade","protocol/fjord/overview.html#execution-layer","protocol/fjord/overview.html#consensus-layer","protocol/fjord/exec-engine.html#l2-execution-engine","protocol/fjord/exec-engine.html#fees","protocol/fjord/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/fjord/exec-engine.html#l1-gas-usage-estimation","protocol/fjord/derivation.html#fjord-l2-chain-derivation-changes","protocol/fjord/derivation.html#protocol-parameter-changes","protocol/fjord/derivation.html#timestamp-activation","protocol/fjord/derivation.html#constant-maximum-sequencer-drift","protocol/fjord/derivation.html#rationale","protocol/fjord/derivation.html#security-considerations","protocol/fjord/derivation.html#increasing-max_rlp_bytes_per_channel-and-max_channel_bank_size","protocol/fjord/derivation.html#rationale-1","protocol/fjord/derivation.html#security-considerations-1","protocol/fjord/derivation.html#brotli-channel-compression","protocol/fjord/derivation.html#network-upgrade-automation-transactions","protocol/fjord/derivation.html#gaspriceoracle-deployment","protocol/fjord/derivation.html#gaspriceoracle-proxy-update","protocol/fjord/derivation.html#gaspriceoracle-enable-fjord","protocol/fjord/predeploys.html#predeploys","protocol/fjord/predeploys.html#gaspriceoracle","protocol/fjord/predeploys.html#l1-gas-usage-estimation","protocol/granite/overview.html#granite-network-upgrade","protocol/granite/overview.html#execution-layer","protocol/granite/overview.html#consensus-layer","protocol/granite/exec-engine.html#l2-execution-engine","protocol/granite/exec-engine.html#evm-changes","protocol/granite/exec-engine.html#bn256pairing-precompile-input-restriction","protocol/granite/derivation.html#granite-l2-chain-derivation-changes","protocol/granite/derivation.html#protocol-parameter-changes","protocol/granite/derivation.html#reduce-channel-timeout","protocol/holocene/overview.html#holocene-network-upgrade","protocol/holocene/overview.html#execution-layer","protocol/holocene/overview.html#consensus-layer","protocol/holocene/overview.html#smart-contracts","protocol/holocene/derivation.html#holocene-l2-chain-derivation-changes","protocol/holocene/derivation.html#holocene-derivation","protocol/holocene/derivation.html#summary","protocol/holocene/derivation.html#frame-queue","protocol/holocene/derivation.html#channel-bank","protocol/holocene/derivation.html#pruning","protocol/holocene/derivation.html#timeout","protocol/holocene/derivation.html#reading--frame-loading","protocol/holocene/derivation.html#span-batches","protocol/holocene/derivation.html#batch-queue","protocol/holocene/derivation.html#fast-channel-invalidation","protocol/holocene/derivation.html#engine-queue","protocol/holocene/derivation.html#attributes-builder","protocol/holocene/derivation.html#activation","protocol/holocene/derivation.html#rationale","protocol/holocene/derivation.html#strict-frame-and-batch-ordering","protocol/holocene/derivation.html#partial-span-batch-validity","protocol/holocene/derivation.html#fast-channel-invalidation-1","protocol/holocene/derivation.html#steady-block-derivation","protocol/holocene/derivation.html#less-defensive-protocol","protocol/holocene/derivation.html#security-and-implementation-considerations","protocol/holocene/derivation.html#reorgs","protocol/holocene/derivation.html#batcher-hardening","protocol/holocene/derivation.html#sync-start","protocol/holocene/exec-engine.html#l2-execution-engine","protocol/holocene/exec-engine.html#timestamp-activation","protocol/holocene/exec-engine.html#l2tol1messagepasser-storage-root-in-header","protocol/holocene/exec-engine.html#header-validity-rules","protocol/holocene/exec-engine.html#header-withdrawals-root","protocol/holocene/exec-engine.html#extended-payloadattributesv3","protocol/holocene/exec-engine.html#eip1559params-encoding","protocol/holocene/exec-engine.html#execution","protocol/holocene/exec-engine.html#rationale","protocol/holocene/exec-engine.html#eip1559params-in-header","protocol/holocene/exec-engine.html#header-validity-rules-1","protocol/holocene/exec-engine.html#encoding","protocol/holocene/exec-engine.html#rationale-1","protocol/holocene/predeploys.html#overview","protocol/holocene/predeploys.html#constants","protocol/holocene/predeploys.html#predeploys","protocol/holocene/predeploys.html#l1block","protocol/holocene/predeploys.html#feevault","protocol/holocene/predeploys.html#l2crossdomainmessenger","protocol/holocene/predeploys.html#l2erc721bridge","protocol/holocene/predeploys.html#l2standardbridge","protocol/holocene/predeploys.html#optimismmintableerc721factory","protocol/holocene/predeploys.html#security-considerations","protocol/holocene/predeploys.html#governancetoken","protocol/holocene/configurability.html#configurability","protocol/holocene/configurability.html#overview","protocol/holocene/configurability.html#constants","protocol/holocene/configurability.html#configtype","protocol/holocene/configurability.html#systemconfig","protocol/holocene/configurability.html#configupdate","protocol/holocene/configurability.html#initialization","protocol/holocene/configurability.html#modifying-eip-1559-parameters","protocol/holocene/configurability.html#interface","protocol/holocene/configurability.html#optimismportal","protocol/holocene/configurability.html#interface-1","governance/gov-token.html#governance-token","governance/gov-token.html#overview","governance/gov-token.html#token-minting","governance/gov-token.html#token-burning","governance/gov-token.html#voting-power","governance/gov-token.html#delegation","experimental/custom-gas-token.html#custom-gas-token","experimental/custom-gas-token.html#overview","experimental/custom-gas-token.html#constants","experimental/custom-gas-token.html#properties-of-a-gas-paying-token","experimental/custom-gas-token.html#automated-validation","experimental/custom-gas-token.html#configuring-the-gas-paying-token","experimental/custom-gas-token.html#contract-modifications","experimental/custom-gas-token.html#igastoken-interface","experimental/custom-gas-token.html#gas-token-aware","experimental/custom-gas-token.html#optimismportal","experimental/custom-gas-token.html#standardbridge","experimental/custom-gas-token.html#crossdomainmessenger","experimental/custom-gas-token.html#systemconfig","experimental/custom-gas-token.html#l1block","experimental/custom-gas-token.html#weth9","experimental/custom-gas-token.html#user-flow","experimental/custom-gas-token.html#when-eth-is-the-native-asset","experimental/custom-gas-token.html#when-an-erc20-token-is-the-native-asset","experimental/custom-gas-token.html#differences","experimental/custom-gas-token.html#upgrade","experimental/custom-gas-token.html#l1block-deployment","experimental/custom-gas-token.html#l2crossdomainmessenger-deployment","experimental/custom-gas-token.html#l2standardbridge-deployment","experimental/custom-gas-token.html#l1block-proxy-update","experimental/custom-gas-token.html#l2crossdomainmessenger-proxy-update","experimental/custom-gas-token.html#l2standardbridge-proxy-update","experimental/custom-gas-token.html#selection-of-ether_token_address","experimental/custom-gas-token.html#standard-config","experimental/custom-gas-token.html#fees","experimental/custom-gas-token.html#security-considerations","experimental/custom-gas-token.html#optimismportal-token-allowance","experimental/custom-gas-token.html#interoperability-support","experimental/custom-gas-token.html#wrapped-ether","experimental/alt-da.html#alt-da-mode","experimental/alt-da.html#overview","experimental/alt-da.html#input-commitment-submission","experimental/alt-da.html#da-server","experimental/alt-da.html#data-availability-challenge-contract","experimental/alt-da.html#parameters","experimental/alt-da.html#derivation","experimental/alt-da.html#fault-proof","experimental/alt-da.html#l2-input","experimental/alt-da.html#l1-challenge-status","experimental/alt-da.html#safety-and-finality","experimental/alt-da.html#security-considerations","interop/overview.html#interop","interop/overview.html#specifications","interop/dependency-set.html#the-dependency-set","interop/dependency-set.html#chain-id","interop/dependency-set.html#updating-the-dependency-set","interop/dependency-set.html#security-considerations","interop/dependency-set.html#layer-1-as-part-of-the-dependency-set","interop/messaging.html#messaging","interop/messaging.html#message","interop/messaging.html#message-payload","interop/messaging.html#message-identifier","interop/messaging.html#messaging-ends","interop/messaging.html#initiating-messages","interop/messaging.html#executing-messages","interop/messaging.html#messaging-invariants","interop/messaging.html#timestamp-invariant","interop/messaging.html#chainid-invariant","interop/messaging.html#message-expiry-invariant","interop/messaging.html#message-graph","interop/messaging.html#invalid-messages","interop/messaging.html#intra-block-messaging-cycles","interop/messaging.html#resolving-cross-chain-safety","interop/messaging.html#horizon-timestamp","interop/messaging.html#pruning-the-graph","interop/messaging.html#bounding-the-graph","interop/messaging.html#security-considerations","interop/messaging.html#cyclic-dependencies","interop/messaging.html#transitive-dependencies","interop/predeploys.html#predeploys","interop/predeploys.html#crossl2inbox","interop/predeploys.html#functions","interop/predeploys.html#interop-start-timestamp","interop/predeploys.html#executingmessage-event","interop/predeploys.html#reference-implementation","interop/predeploys.html#deposit-handling","interop/predeploys.html#identifier-getters","interop/predeploys.html#l2tol2crossdomainmessenger","interop/predeploys.html#relaymessage-invariants","interop/predeploys.html#sendexpire-invariants","interop/predeploys.html#relayexpire-invariants","interop/predeploys.html#message-versioning","interop/predeploys.html#no-native-support-for-cross-chain-ether-sends","interop/predeploys.html#interfaces","interop/predeploys.html#optimismsuperchainerc20factory","interop/predeploys.html#optimismsuperchainerc20","interop/predeploys.html#overview","interop/predeploys.html#functions-1","interop/predeploys.html#events","interop/predeploys.html#deployment-flow","interop/predeploys.html#beaconcontract","interop/predeploys.html#overview-1","interop/predeploys.html#l1block","interop/predeploys.html#static-configuration","interop/predeploys.html#dependency-set","interop/predeploys.html#deposit-context","interop/predeploys.html#isdeposit","interop/predeploys.html#optimismmintableerc20factory","interop/predeploys.html#optimismmintableerc20","interop/predeploys.html#updates","interop/predeploys.html#functions-2","interop/predeploys.html#events-1","interop/predeploys.html#l2standardbridge","interop/predeploys.html#updates-1","interop/predeploys.html#invariants","interop/predeploys.html#conversion-flow","interop/predeploys.html#superchainerc20bridge","interop/predeploys.html#overview-2","interop/predeploys.html#functions-3","interop/predeploys.html#events-2","interop/predeploys.html#diagram","interop/predeploys.html#invariants-1","interop/predeploys.html#security-considerations","interop/sequencer.html#sequencer","interop/sequencer.html#sequencer-policy","interop/sequencer.html#block-building","interop/sequencer.html#static-analysis","interop/sequencer.html#dependency-confirmations","interop/sequencer.html#sponsorship","interop/sequencer.html#security-considerations","interop/sequencer.html#cross-chain-message-latency","interop/verifier.html#verifier","interop/verifier.html#derivation-pipeline","interop/verifier.html#depositing-an-executing-message","interop/verifier.html#safety","interop/verifier.html#honest-verifier","interop/verifier.html#security-considerations","interop/verifier.html#forced-inclusion-of-cross-chain-messages","interop/verifier.html#reliance-on-history","interop/rollup-node-p2p.html#p2p-networking","interop/rollup-node-p2p.html#security-considerations","interop/fault-proof.html#fault-proof","interop/fault-proof.html#cascading-dependencies","interop/fault-proof.html#security-considerations","interop/upgrade.html#interop-network-upgrade","interop/upgrade.html#l1-attributes","interop/upgrade.html#l1-attributes-predeployed-contract","interop/upgrade.html#interop-l1block-upgrade","interop/upgrade.html#security-considerations","interop/token-bridging.html#token-bridging","interop/token-bridging.html#overview","interop/token-bridging.html#superchainerc20-standard","interop/token-bridging.html#properties","interop/token-bridging.html#interface","interop/token-bridging.html#superchainerc20bridge","interop/token-bridging.html#diagram","interop/token-bridging.html#implementation","interop/token-bridging.html#future-considerations","interop/token-bridging.html#cross-chain-transferfrom","interop/token-bridging.html#concatenated-action","interop/superchain-weth.html#superchain-weth","interop/superchain-weth.html#motivation-and-constraints","interop/superchain-weth.html#handling-native-assets-other-than-eth","interop/superchain-weth.html#minimizing-protocol-complexity","interop/superchain-weth.html#constants","interop/superchain-weth.html#superchainweth","interop/superchain-weth.html#invariants","interop/superchain-weth.html#ethliquidity","interop/superchain-weth.html#invariants-1","interop/derivation.html#derivation","interop/derivation.html#overview","interop/derivation.html#deposit-context","interop/derivation.html#security-considerations","interop/derivation.html#gas-considerations","interop/tx-pool.html#transaction-pool","interop/tx-pool.html#message-validation","interop/tx-pool.html#system-deposits-transaction-margin","interop/tx-pool.html#security-considerations","interop/tx-pool.html#mempool-denial-of-service","experimental/op-contracts-manager.html#op-contracts-manager","experimental/op-contracts-manager.html#deployment","experimental/op-contracts-manager.html#interface","experimental/op-contracts-manager.html#proxysol","experimental/op-contracts-manager.html#deploy","experimental/op-contracts-manager.html#getter-methods","experimental/op-contracts-manager.html#implementation","experimental/op-contracts-manager.html#batch-inbox-address","experimental/op-contracts-manager.html#contract-deployments","experimental/op-contracts-manager.html#security-considerations","experimental/op-contracts-manager.html#chain-id-source-of-truth","experimental/op-contracts-manager.html#chain-id-frontrunning","experimental/op-contracts-manager.html#chain-id-value","experimental/op-contracts-manager.html#proxy-admin-owner","experimental/op-contracts-manager.html#upgradeability-abi-changes","experimental/gov-token.html#governance-token","experimental/gov-token.html#overview","experimental/gov-token.html#hook-based-integration-with-governancedelegation","experimental/gov-token.html#token-minting","experimental/gov-token.html#token-burning","experimental/gov-token.html#voting-power","experimental/gov-token.html#delegation","glossary.html#glossary","glossary.html#general-terms","glossary.html#layer-1-l1","glossary.html#layer-2-l2","glossary.html#block","glossary.html#eoa","glossary.html#merkle-patricia-trie","glossary.html#chain-re-organization","glossary.html#predeployed-contract-predeploy","glossary.html#preinstalled-contract-preinstall","glossary.html#precompiled-contract-precompile","glossary.html#receipt","glossary.html#transaction-type","glossary.html#fork-choice-rule","glossary.html#priority-gas-auction","glossary.html#sequencing","glossary.html#sequencer","glossary.html#sequencing-window","glossary.html#sequencing-epoch","glossary.html#l1-origin","glossary.html#deposits","glossary.html#deposited-transaction","glossary.html#l1-attributes-deposited-transaction","glossary.html#user-deposited-transaction","glossary.html#depositing-call","glossary.html#depositing-transaction","glossary.html#depositor","glossary.html#deposited-transaction-type","glossary.html#deposit-contract","glossary.html#withdrawals","glossary.html#relayer","glossary.html#finalization-period","glossary.html#batch-submission","glossary.html#data-availability","glossary.html#data-availability-provider","glossary.html#sequencer-batch","glossary.html#channel","glossary.html#channel-frame","glossary.html#batcher","glossary.html#batcher-transaction","glossary.html#batch-submission-frequency","glossary.html#channel-timeout","glossary.html#l2-output-root-proposals","glossary.html#proposer","glossary.html#l2-chain-derivation","glossary.html#l2-derivation-inputs","glossary.html#system-configuration","glossary.html#payload-attributes","glossary.html#l2-genesis-block","glossary.html#l2-chain-inception","glossary.html#safe-l2-block","glossary.html#safe-l2-head","glossary.html#unsafe-l2-block","glossary.html#unsafe-l2-head","glossary.html#unsafe-block-consolidation","glossary.html#finalized-l2-head","glossary.html#other-l2-chain-concepts","glossary.html#address-aliasing","glossary.html#rollup-node","glossary.html#rollup-driver","glossary.html#l1-attributes-predeployed-contract","glossary.html#l2-output-root","glossary.html#l2-output-oracle-contract","glossary.html#validator","glossary.html#fault-proof","glossary.html#time-slot","glossary.html#block-time","glossary.html#unsafe-sync","glossary.html#execution-engine-concepts","glossary.html#execution-engine"],"index":{"documentStore":{"docInfo":{"0":{"body":7,"breadcrumbs":4,"title":3},"1":{"body":51,"breadcrumbs":2,"title":1},"10":{"body":17,"breadcrumbs":3,"title":2},"100":{"body":260,"breadcrumbs":7,"title":1},"101":{"body":81,"breadcrumbs":7,"title":1},"102":{"body":7,"breadcrumbs":7,"title":1},"103":{"body":30,"breadcrumbs":7,"title":1},"104":{"body":9,"breadcrumbs":7,"title":1},"105":{"body":36,"breadcrumbs":7,"title":1},"106":{"body":72,"breadcrumbs":7,"title":1},"107":{"body":99,"breadcrumbs":7,"title":1},"108":{"body":53,"breadcrumbs":7,"title":1},"109":{"body":99,"breadcrumbs":9,"title":3},"11":{"body":33,"breadcrumbs":2,"title":1},"110":{"body":47,"breadcrumbs":9,"title":3},"111":{"body":97,"breadcrumbs":10,"title":4},"112":{"body":80,"breadcrumbs":10,"title":4},"113":{"body":31,"breadcrumbs":8,"title":2},"114":{"body":20,"breadcrumbs":9,"title":3},"115":{"body":26,"breadcrumbs":7,"title":1},"116":{"body":26,"breadcrumbs":7,"title":1},"117":{"body":85,"breadcrumbs":7,"title":1},"118":{"body":13,"breadcrumbs":10,"title":4},"119":{"body":112,"breadcrumbs":7,"title":1},"12":{"body":30,"breadcrumbs":2,"title":1},"120":{"body":57,"breadcrumbs":9,"title":3},"121":{"body":61,"breadcrumbs":9,"title":3},"122":{"body":60,"breadcrumbs":13,"title":4},"123":{"body":143,"breadcrumbs":10,"title":1},"124":{"body":0,"breadcrumbs":11,"title":2},"125":{"body":69,"breadcrumbs":10,"title":1},"126":{"body":149,"breadcrumbs":10,"title":1},"127":{"body":576,"breadcrumbs":10,"title":1},"128":{"body":9,"breadcrumbs":11,"title":2},"129":{"body":5,"breadcrumbs":10,"title":1},"13":{"body":29,"breadcrumbs":2,"title":1},"130":{"body":4,"breadcrumbs":10,"title":1},"131":{"body":4,"breadcrumbs":10,"title":1},"132":{"body":71,"breadcrumbs":11,"title":2},"133":{"body":42,"breadcrumbs":11,"title":2},"134":{"body":233,"breadcrumbs":11,"title":2},"135":{"body":167,"breadcrumbs":11,"title":2},"136":{"body":255,"breadcrumbs":10,"title":1},"137":{"body":130,"breadcrumbs":11,"title":4},"138":{"body":420,"breadcrumbs":8,"title":1},"139":{"body":59,"breadcrumbs":10,"title":3},"14":{"body":84,"breadcrumbs":3,"title":2},"140":{"body":49,"breadcrumbs":9,"title":2},"141":{"body":0,"breadcrumbs":9,"title":2},"142":{"body":147,"breadcrumbs":11,"title":4},"143":{"body":478,"breadcrumbs":11,"title":4},"144":{"body":64,"breadcrumbs":10,"title":3},"145":{"body":115,"breadcrumbs":9,"title":2},"146":{"body":133,"breadcrumbs":9,"title":2},"147":{"body":120,"breadcrumbs":9,"title":2},"148":{"body":33,"breadcrumbs":8,"title":1},"149":{"body":143,"breadcrumbs":11,"title":4},"15":{"body":18,"breadcrumbs":2,"title":1},"150":{"body":47,"breadcrumbs":9,"title":2},"151":{"body":68,"breadcrumbs":9,"title":2},"152":{"body":20,"breadcrumbs":9,"title":2},"153":{"body":311,"breadcrumbs":9,"title":2},"154":{"body":19,"breadcrumbs":11,"title":4},"155":{"body":480,"breadcrumbs":9,"title":2},"156":{"body":57,"breadcrumbs":10,"title":3},"157":{"body":874,"breadcrumbs":9,"title":2},"158":{"body":581,"breadcrumbs":9,"title":2},"159":{"body":43,"breadcrumbs":10,"title":3},"16":{"body":103,"breadcrumbs":2,"title":1},"160":{"body":140,"breadcrumbs":10,"title":3},"161":{"body":700,"breadcrumbs":11,"title":4},"162":{"body":65,"breadcrumbs":11,"title":4},"163":{"body":3,"breadcrumbs":8,"title":2},"164":{"body":116,"breadcrumbs":7,"title":1},"165":{"body":114,"breadcrumbs":7,"title":2},"166":{"body":77,"breadcrumbs":6,"title":1},"167":{"body":52,"breadcrumbs":8,"title":3},"168":{"body":548,"breadcrumbs":9,"title":4},"169":{"body":51,"breadcrumbs":6,"title":1},"17":{"body":62,"breadcrumbs":2,"title":1},"170":{"body":215,"breadcrumbs":6,"title":1},"171":{"body":128,"breadcrumbs":8,"title":3},"172":{"body":55,"breadcrumbs":8,"title":3},"173":{"body":146,"breadcrumbs":6,"title":1},"174":{"body":252,"breadcrumbs":7,"title":2},"175":{"body":142,"breadcrumbs":6,"title":1},"176":{"body":190,"breadcrumbs":9,"title":4},"177":{"body":55,"breadcrumbs":7,"title":2},"178":{"body":104,"breadcrumbs":8,"title":3},"179":{"body":88,"breadcrumbs":10,"title":5},"18":{"body":0,"breadcrumbs":4,"title":3},"180":{"body":30,"breadcrumbs":14,"title":5},"181":{"body":75,"breadcrumbs":10,"title":1},"182":{"body":116,"breadcrumbs":10,"title":1},"183":{"body":51,"breadcrumbs":11,"title":2},"184":{"body":59,"breadcrumbs":10,"title":1},"185":{"body":82,"breadcrumbs":10,"title":1},"186":{"body":63,"breadcrumbs":11,"title":2},"187":{"body":165,"breadcrumbs":10,"title":1},"188":{"body":126,"breadcrumbs":10,"title":1},"189":{"body":26,"breadcrumbs":11,"title":2},"19":{"body":93,"breadcrumbs":4,"title":3},"190":{"body":22,"breadcrumbs":11,"title":2},"191":{"body":162,"breadcrumbs":12,"title":3},"192":{"body":68,"breadcrumbs":10,"title":1},"193":{"body":0,"breadcrumbs":11,"title":2},"194":{"body":147,"breadcrumbs":11,"title":2},"195":{"body":121,"breadcrumbs":11,"title":2},"196":{"body":19,"breadcrumbs":11,"title":3},"197":{"body":8,"breadcrumbs":14,"title":3},"198":{"body":74,"breadcrumbs":12,"title":1},"199":{"body":179,"breadcrumbs":12,"title":1},"2":{"body":28,"breadcrumbs":3,"title":2},"20":{"body":141,"breadcrumbs":2,"title":1},"200":{"body":614,"breadcrumbs":13,"title":2},"201":{"body":348,"breadcrumbs":13,"title":2},"202":{"body":52,"breadcrumbs":14,"title":3},"203":{"body":79,"breadcrumbs":12,"title":1},"204":{"body":0,"breadcrumbs":12,"title":1},"205":{"body":44,"breadcrumbs":14,"title":3},"206":{"body":31,"breadcrumbs":12,"title":1},"207":{"body":25,"breadcrumbs":13,"title":2},"208":{"body":64,"breadcrumbs":12,"title":1},"209":{"body":78,"breadcrumbs":13,"title":2},"21":{"body":19,"breadcrumbs":3,"title":2},"210":{"body":29,"breadcrumbs":14,"title":3},"211":{"body":34,"breadcrumbs":12,"title":1},"212":{"body":80,"breadcrumbs":12,"title":1},"213":{"body":68,"breadcrumbs":13,"title":2},"214":{"body":112,"breadcrumbs":12,"title":1},"215":{"body":12,"breadcrumbs":12,"title":1},"216":{"body":15,"breadcrumbs":12,"title":1},"217":{"body":92,"breadcrumbs":13,"title":2},"218":{"body":22,"breadcrumbs":14,"title":3},"219":{"body":32,"breadcrumbs":12,"title":1},"22":{"body":72,"breadcrumbs":5,"title":2},"220":{"body":216,"breadcrumbs":12,"title":1},"221":{"body":110,"breadcrumbs":15,"title":4},"222":{"body":122,"breadcrumbs":12,"title":1},"223":{"body":123,"breadcrumbs":13,"title":2},"224":{"body":428,"breadcrumbs":13,"title":2},"225":{"body":58,"breadcrumbs":13,"title":2},"226":{"body":128,"breadcrumbs":13,"title":2},"227":{"body":229,"breadcrumbs":12,"title":1},"228":{"body":87,"breadcrumbs":12,"title":1},"229":{"body":12,"breadcrumbs":18,"title":5},"23":{"body":98,"breadcrumbs":6,"title":3},"230":{"body":90,"breadcrumbs":14,"title":1},"231":{"body":39,"breadcrumbs":14,"title":1},"232":{"body":93,"breadcrumbs":17,"title":4},"233":{"body":52,"breadcrumbs":14,"title":1},"234":{"body":65,"breadcrumbs":14,"title":1},"235":{"body":11,"breadcrumbs":14,"title":1},"236":{"body":64,"breadcrumbs":14,"title":1},"237":{"body":31,"breadcrumbs":15,"title":2},"238":{"body":65,"breadcrumbs":14,"title":1},"239":{"body":60,"breadcrumbs":14,"title":1},"24":{"body":0,"breadcrumbs":5,"title":2},"240":{"body":42,"breadcrumbs":15,"title":2},"241":{"body":53,"breadcrumbs":16,"title":3},"242":{"body":15,"breadcrumbs":17,"title":4},"243":{"body":27,"breadcrumbs":15,"title":2},"244":{"body":37,"breadcrumbs":16,"title":3},"245":{"body":90,"breadcrumbs":15,"title":2},"246":{"body":23,"breadcrumbs":16,"title":3},"247":{"body":31,"breadcrumbs":14,"title":1},"248":{"body":367,"breadcrumbs":14,"title":1},"249":{"body":54,"breadcrumbs":12,"title":2},"25":{"body":394,"breadcrumbs":7,"title":4},"250":{"body":27,"breadcrumbs":11,"title":1},"251":{"body":151,"breadcrumbs":12,"title":2},"252":{"body":0,"breadcrumbs":14,"title":4},"253":{"body":10,"breadcrumbs":12,"title":2},"254":{"body":39,"breadcrumbs":13,"title":3},"255":{"body":42,"breadcrumbs":12,"title":2},"256":{"body":96,"breadcrumbs":12,"title":2},"257":{"body":168,"breadcrumbs":12,"title":2},"258":{"body":122,"breadcrumbs":12,"title":2},"259":{"body":168,"breadcrumbs":12,"title":2},"26":{"body":251,"breadcrumbs":7,"title":4},"260":{"body":23,"breadcrumbs":12,"title":2},"261":{"body":43,"breadcrumbs":12,"title":2},"262":{"body":12,"breadcrumbs":12,"title":2},"263":{"body":43,"breadcrumbs":11,"title":1},"264":{"body":4,"breadcrumbs":5,"title":1},"265":{"body":61,"breadcrumbs":5,"title":1},"266":{"body":35,"breadcrumbs":5,"title":1},"267":{"body":24,"breadcrumbs":5,"title":1},"268":{"body":168,"breadcrumbs":5,"title":1},"269":{"body":71,"breadcrumbs":5,"title":1},"27":{"body":70,"breadcrumbs":6,"title":3},"270":{"body":33,"breadcrumbs":5,"title":1},"271":{"body":48,"breadcrumbs":5,"title":1},"272":{"body":41,"breadcrumbs":5,"title":1},"273":{"body":19,"breadcrumbs":5,"title":1},"274":{"body":59,"breadcrumbs":5,"title":1},"275":{"body":84,"breadcrumbs":5,"title":1},"276":{"body":30,"breadcrumbs":5,"title":1},"277":{"body":141,"breadcrumbs":5,"title":1},"278":{"body":16,"breadcrumbs":5,"title":1},"279":{"body":18,"breadcrumbs":5,"title":1},"28":{"body":142,"breadcrumbs":6,"title":3},"280":{"body":29,"breadcrumbs":5,"title":1},"281":{"body":43,"breadcrumbs":5,"title":1},"282":{"body":14,"breadcrumbs":5,"title":1},"283":{"body":25,"breadcrumbs":5,"title":1},"284":{"body":21,"breadcrumbs":5,"title":1},"285":{"body":13,"breadcrumbs":5,"title":1},"286":{"body":10,"breadcrumbs":5,"title":1},"287":{"body":18,"breadcrumbs":7,"title":3},"288":{"body":32,"breadcrumbs":5,"title":1},"289":{"body":96,"breadcrumbs":5,"title":1},"29":{"body":56,"breadcrumbs":5,"title":2},"290":{"body":18,"breadcrumbs":5,"title":1},"291":{"body":16,"breadcrumbs":5,"title":1},"292":{"body":8,"breadcrumbs":5,"title":1},"293":{"body":9,"breadcrumbs":5,"title":1},"294":{"body":51,"breadcrumbs":5,"title":1},"295":{"body":24,"breadcrumbs":5,"title":1},"296":{"body":127,"breadcrumbs":5,"title":1},"297":{"body":26,"breadcrumbs":5,"title":1},"298":{"body":87,"breadcrumbs":8,"title":4},"299":{"body":22,"breadcrumbs":5,"title":1},"3":{"body":17,"breadcrumbs":3,"title":2},"30":{"body":0,"breadcrumbs":6,"title":3},"300":{"body":12,"breadcrumbs":8,"title":4},"301":{"body":14,"breadcrumbs":8,"title":4},"302":{"body":12,"breadcrumbs":8,"title":4},"303":{"body":14,"breadcrumbs":8,"title":4},"304":{"body":13,"breadcrumbs":8,"title":2},"305":{"body":14,"breadcrumbs":7,"title":1},"306":{"body":25,"breadcrumbs":8,"title":2},"307":{"body":29,"breadcrumbs":9,"title":3},"308":{"body":70,"breadcrumbs":7,"title":1},"309":{"body":52,"breadcrumbs":8,"title":2},"31":{"body":69,"breadcrumbs":4,"title":1},"310":{"body":57,"breadcrumbs":7,"title":1},"311":{"body":123,"breadcrumbs":8,"title":2},"312":{"body":326,"breadcrumbs":9,"title":3},"313":{"body":36,"breadcrumbs":9,"title":3},"314":{"body":42,"breadcrumbs":8,"title":2},"315":{"body":88,"breadcrumbs":9,"title":3},"316":{"body":47,"breadcrumbs":9,"title":3},"317":{"body":58,"breadcrumbs":8,"title":2},"318":{"body":72,"breadcrumbs":12,"title":6},"319":{"body":100,"breadcrumbs":11,"title":5},"32":{"body":326,"breadcrumbs":5,"title":2},"320":{"body":130,"breadcrumbs":10,"title":4},"321":{"body":0,"breadcrumbs":10,"title":4},"322":{"body":49,"breadcrumbs":8,"title":2},"323":{"body":31,"breadcrumbs":7,"title":2},"324":{"body":19,"breadcrumbs":6,"title":1},"325":{"body":8,"breadcrumbs":10,"title":5},"326":{"body":43,"breadcrumbs":7,"title":2},"327":{"body":287,"breadcrumbs":6,"title":1},"328":{"body":51,"breadcrumbs":7,"title":2},"329":{"body":51,"breadcrumbs":7,"title":2},"33":{"body":139,"breadcrumbs":5,"title":2},"330":{"body":33,"breadcrumbs":8,"title":3},"331":{"body":219,"breadcrumbs":8,"title":3},"332":{"body":256,"breadcrumbs":7,"title":3},"333":{"body":0,"breadcrumbs":6,"title":2},"334":{"body":26,"breadcrumbs":7,"title":3},"335":{"body":22,"breadcrumbs":6,"title":2},"336":{"body":29,"breadcrumbs":6,"title":2},"337":{"body":41,"breadcrumbs":7,"title":3},"338":{"body":34,"breadcrumbs":7,"title":3},"339":{"body":31,"breadcrumbs":7,"title":3},"34":{"body":6,"breadcrumbs":6,"title":2},"340":{"body":25,"breadcrumbs":8,"title":4},"341":{"body":32,"breadcrumbs":8,"title":4},"342":{"body":26,"breadcrumbs":8,"title":4},"343":{"body":27,"breadcrumbs":7,"title":3},"344":{"body":27,"breadcrumbs":7,"title":3},"345":{"body":36,"breadcrumbs":9,"title":5},"346":{"body":28,"breadcrumbs":9,"title":5},"347":{"body":34,"breadcrumbs":8,"title":4},"348":{"body":30,"breadcrumbs":8,"title":4},"349":{"body":18,"breadcrumbs":9,"title":5},"35":{"body":186,"breadcrumbs":5,"title":1},"350":{"body":20,"breadcrumbs":6,"title":2},"351":{"body":31,"breadcrumbs":6,"title":2},"352":{"body":29,"breadcrumbs":6,"title":2},"353":{"body":24,"breadcrumbs":7,"title":3},"354":{"body":26,"breadcrumbs":6,"title":2},"355":{"body":48,"breadcrumbs":7,"title":3},"356":{"body":19,"breadcrumbs":6,"title":2},"357":{"body":35,"breadcrumbs":6,"title":2},"358":{"body":23,"breadcrumbs":6,"title":2},"359":{"body":18,"breadcrumbs":6,"title":2},"36":{"body":24,"breadcrumbs":6,"title":2},"360":{"body":0,"breadcrumbs":6,"title":2},"361":{"body":34,"breadcrumbs":7,"title":3},"362":{"body":48,"breadcrumbs":7,"title":3},"363":{"body":39,"breadcrumbs":6,"title":2},"364":{"body":0,"breadcrumbs":6,"title":2},"365":{"body":52,"breadcrumbs":7,"title":3},"366":{"body":20,"breadcrumbs":7,"title":3},"367":{"body":31,"breadcrumbs":7,"title":3},"368":{"body":37,"breadcrumbs":7,"title":3},"369":{"body":83,"breadcrumbs":7,"title":3},"37":{"body":8,"breadcrumbs":5,"title":1},"370":{"body":0,"breadcrumbs":6,"title":2},"371":{"body":15,"breadcrumbs":7,"title":3},"372":{"body":33,"breadcrumbs":6,"title":2},"373":{"body":37,"breadcrumbs":6,"title":2},"374":{"body":39,"breadcrumbs":6,"title":2},"375":{"body":28,"breadcrumbs":9,"title":5},"376":{"body":128,"breadcrumbs":8,"title":3},"377":{"body":6,"breadcrumbs":7,"title":2},"378":{"body":178,"breadcrumbs":8,"title":3},"379":{"body":58,"breadcrumbs":10,"title":5},"38":{"body":17,"breadcrumbs":8,"title":3},"380":{"body":52,"breadcrumbs":10,"title":5},"381":{"body":94,"breadcrumbs":7,"title":2},"382":{"body":52,"breadcrumbs":7,"title":2},"383":{"body":51,"breadcrumbs":9,"title":4},"384":{"body":23,"breadcrumbs":6,"title":1},"385":{"body":126,"breadcrumbs":8,"title":3},"386":{"body":29,"breadcrumbs":11,"title":6},"387":{"body":0,"breadcrumbs":7,"title":2},"388":{"body":22,"breadcrumbs":10,"title":5},"389":{"body":62,"breadcrumbs":9,"title":4},"39":{"body":186,"breadcrumbs":6,"title":1},"390":{"body":76,"breadcrumbs":9,"title":4},"391":{"body":14,"breadcrumbs":13,"title":4},"392":{"body":20,"breadcrumbs":10,"title":1},"393":{"body":7,"breadcrumbs":12,"title":3},"394":{"body":82,"breadcrumbs":12,"title":3},"395":{"body":177,"breadcrumbs":11,"title":2},"396":{"body":134,"breadcrumbs":12,"title":3},"397":{"body":3,"breadcrumbs":7,"title":1},"398":{"body":158,"breadcrumbs":7,"title":1},"399":{"body":40,"breadcrumbs":7,"title":1},"4":{"body":29,"breadcrumbs":2,"title":1},"40":{"body":75,"breadcrumbs":7,"title":2},"400":{"body":51,"breadcrumbs":8,"title":2},"401":{"body":3,"breadcrumbs":8,"title":2},"402":{"body":16,"breadcrumbs":7,"title":1},"403":{"body":9,"breadcrumbs":8,"title":2},"404":{"body":70,"breadcrumbs":10,"title":2},"405":{"body":150,"breadcrumbs":9,"title":1},"406":{"body":314,"breadcrumbs":11,"title":3},"407":{"body":38,"breadcrumbs":12,"title":4},"408":{"body":74,"breadcrumbs":12,"title":4},"409":{"body":41,"breadcrumbs":12,"title":4},"41":{"body":13,"breadcrumbs":6,"title":1},"410":{"body":0,"breadcrumbs":10,"title":2},"411":{"body":27,"breadcrumbs":13,"title":5},"412":{"body":19,"breadcrumbs":12,"title":4},"413":{"body":20,"breadcrumbs":13,"title":5},"414":{"body":24,"breadcrumbs":13,"title":5},"415":{"body":44,"breadcrumbs":13,"title":5},"416":{"body":64,"breadcrumbs":13,"title":5},"417":{"body":32,"breadcrumbs":14,"title":6},"418":{"body":75,"breadcrumbs":11,"title":3},"419":{"body":142,"breadcrumbs":12,"title":4},"42":{"body":36,"breadcrumbs":7,"title":2},"420":{"body":0,"breadcrumbs":9,"title":1},"421":{"body":18,"breadcrumbs":12,"title":4},"422":{"body":482,"breadcrumbs":10,"title":2},"423":{"body":101,"breadcrumbs":9,"title":1},"424":{"body":18,"breadcrumbs":9,"title":3},"425":{"body":80,"breadcrumbs":8,"title":2},"426":{"body":30,"breadcrumbs":8,"title":2},"427":{"body":7,"breadcrumbs":8,"title":1},"428":{"body":110,"breadcrumbs":10,"title":3},"429":{"body":279,"breadcrumbs":9,"title":2},"43":{"body":6,"breadcrumbs":8,"title":3},"430":{"body":10,"breadcrumbs":11,"title":3},"431":{"body":203,"breadcrumbs":9,"title":1},"432":{"body":116,"breadcrumbs":12,"title":4},"433":{"body":111,"breadcrumbs":11,"title":3},"434":{"body":6,"breadcrumbs":9,"title":3},"435":{"body":22,"breadcrumbs":8,"title":2},"436":{"body":16,"breadcrumbs":8,"title":2},"437":{"body":27,"breadcrumbs":11,"title":3},"438":{"body":0,"breadcrumbs":9,"title":1},"439":{"body":266,"breadcrumbs":14,"title":6},"44":{"body":8,"breadcrumbs":8,"title":3},"440":{"body":24,"breadcrumbs":12,"title":4},"441":{"body":35,"breadcrumbs":12,"title":5},"442":{"body":35,"breadcrumbs":10,"title":3},"443":{"body":51,"breadcrumbs":9,"title":2},"444":{"body":34,"breadcrumbs":11,"title":4},"445":{"body":53,"breadcrumbs":8,"title":1},"446":{"body":66,"breadcrumbs":9,"title":2},"447":{"body":57,"breadcrumbs":10,"title":3},"448":{"body":110,"breadcrumbs":8,"title":1},"449":{"body":115,"breadcrumbs":9,"title":2},"45":{"body":45,"breadcrumbs":8,"title":3},"450":{"body":75,"breadcrumbs":10,"title":3},"451":{"body":43,"breadcrumbs":11,"title":4},"452":{"body":106,"breadcrumbs":9,"title":2},"453":{"body":75,"breadcrumbs":10,"title":3},"454":{"body":66,"breadcrumbs":10,"title":3},"455":{"body":7,"breadcrumbs":8,"title":1},"456":{"body":130,"breadcrumbs":8,"title":1},"457":{"body":91,"breadcrumbs":11,"title":4},"458":{"body":6,"breadcrumbs":9,"title":3},"459":{"body":5,"breadcrumbs":8,"title":2},"46":{"body":64,"breadcrumbs":6,"title":1},"460":{"body":4,"breadcrumbs":8,"title":2},"461":{"body":8,"breadcrumbs":11,"title":3},"462":{"body":0,"breadcrumbs":10,"title":2},"463":{"body":25,"breadcrumbs":12,"title":4},"464":{"body":8,"breadcrumbs":12,"title":5},"465":{"body":20,"breadcrumbs":10,"title":3},"466":{"body":18,"breadcrumbs":10,"title":3},"467":{"body":12,"breadcrumbs":9,"title":3},"468":{"body":4,"breadcrumbs":8,"title":2},"469":{"body":2,"breadcrumbs":8,"title":2},"47":{"body":40,"breadcrumbs":6,"title":1},"470":{"body":2,"breadcrumbs":8,"title":2},"471":{"body":52,"breadcrumbs":12,"title":5},"472":{"body":0,"breadcrumbs":9,"title":2},"473":{"body":114,"breadcrumbs":8,"title":1},"474":{"body":174,"breadcrumbs":9,"title":2},"475":{"body":13,"breadcrumbs":9,"title":2},"476":{"body":32,"breadcrumbs":8,"title":1},"477":{"body":6,"breadcrumbs":8,"title":1},"478":{"body":77,"breadcrumbs":10,"title":3},"479":{"body":167,"breadcrumbs":9,"title":2},"48":{"body":205,"breadcrumbs":8,"title":3},"480":{"body":83,"breadcrumbs":9,"title":2},"481":{"body":39,"breadcrumbs":10,"title":3},"482":{"body":40,"breadcrumbs":9,"title":2},"483":{"body":72,"breadcrumbs":9,"title":2},"484":{"body":102,"breadcrumbs":8,"title":1},"485":{"body":0,"breadcrumbs":8,"title":1},"486":{"body":65,"breadcrumbs":11,"title":4},"487":{"body":59,"breadcrumbs":11,"title":4},"488":{"body":38,"breadcrumbs":10,"title":3},"489":{"body":54,"breadcrumbs":10,"title":3},"49":{"body":114,"breadcrumbs":8,"title":3},"490":{"body":70,"breadcrumbs":10,"title":3},"491":{"body":0,"breadcrumbs":10,"title":3},"492":{"body":85,"breadcrumbs":8,"title":1},"493":{"body":186,"breadcrumbs":9,"title":2},"494":{"body":180,"breadcrumbs":9,"title":2},"495":{"body":34,"breadcrumbs":11,"title":3},"496":{"body":15,"breadcrumbs":10,"title":2},"497":{"body":30,"breadcrumbs":12,"title":4},"498":{"body":40,"breadcrumbs":11,"title":3},"499":{"body":155,"breadcrumbs":11,"title":3},"5":{"body":40,"breadcrumbs":2,"title":1},"50":{"body":57,"breadcrumbs":8,"title":3},"500":{"body":33,"breadcrumbs":10,"title":2},"501":{"body":16,"breadcrumbs":10,"title":2},"502":{"body":45,"breadcrumbs":9,"title":1},"503":{"body":31,"breadcrumbs":9,"title":1},"504":{"body":13,"breadcrumbs":10,"title":2},"505":{"body":23,"breadcrumbs":11,"title":3},"506":{"body":6,"breadcrumbs":9,"title":1},"507":{"body":53,"breadcrumbs":9,"title":1},"508":{"body":53,"breadcrumbs":8,"title":1},"509":{"body":89,"breadcrumbs":8,"title":1},"51":{"body":24,"breadcrumbs":9,"title":4},"510":{"body":65,"breadcrumbs":8,"title":1},"511":{"body":149,"breadcrumbs":8,"title":1},"512":{"body":37,"breadcrumbs":8,"title":1},"513":{"body":11,"breadcrumbs":8,"title":1},"514":{"body":11,"breadcrumbs":8,"title":1},"515":{"body":11,"breadcrumbs":8,"title":1},"516":{"body":11,"breadcrumbs":8,"title":1},"517":{"body":0,"breadcrumbs":9,"title":2},"518":{"body":9,"breadcrumbs":8,"title":1},"519":{"body":28,"breadcrumbs":8,"title":1},"52":{"body":370,"breadcrumbs":6,"title":1},"520":{"body":7,"breadcrumbs":8,"title":1},"521":{"body":0,"breadcrumbs":8,"title":1},"522":{"body":58,"breadcrumbs":8,"title":1},"523":{"body":0,"breadcrumbs":8,"title":1},"524":{"body":56,"breadcrumbs":8,"title":1},"525":{"body":28,"breadcrumbs":8,"title":1},"526":{"body":15,"breadcrumbs":11,"title":4},"527":{"body":84,"breadcrumbs":8,"title":1},"528":{"body":7,"breadcrumbs":8,"title":1},"529":{"body":53,"breadcrumbs":8,"title":1},"53":{"body":146,"breadcrumbs":7,"title":2},"530":{"body":15,"breadcrumbs":5,"title":2},"531":{"body":49,"breadcrumbs":4,"title":1},"532":{"body":26,"breadcrumbs":5,"title":2},"533":{"body":25,"breadcrumbs":5,"title":2},"534":{"body":94,"breadcrumbs":5,"title":2},"535":{"body":37,"breadcrumbs":4,"title":1},"536":{"body":73,"breadcrumbs":7,"title":3},"537":{"body":83,"breadcrumbs":5,"title":1},"538":{"body":50,"breadcrumbs":5,"title":1},"539":{"body":77,"breadcrumbs":8,"title":4},"54":{"body":70,"breadcrumbs":9,"title":4},"540":{"body":50,"breadcrumbs":6,"title":2},"541":{"body":146,"breadcrumbs":8,"title":4},"542":{"body":0,"breadcrumbs":6,"title":2},"543":{"body":80,"breadcrumbs":6,"title":2},"544":{"body":20,"breadcrumbs":7,"title":3},"545":{"body":188,"breadcrumbs":5,"title":1},"546":{"body":65,"breadcrumbs":5,"title":1},"547":{"body":90,"breadcrumbs":5,"title":1},"548":{"body":85,"breadcrumbs":5,"title":1},"549":{"body":54,"breadcrumbs":5,"title":1},"55":{"body":25,"breadcrumbs":10,"title":5},"550":{"body":23,"breadcrumbs":5,"title":1},"551":{"body":39,"breadcrumbs":6,"title":2},"552":{"body":72,"breadcrumbs":7,"title":3},"553":{"body":86,"breadcrumbs":8,"title":4},"554":{"body":26,"breadcrumbs":5,"title":1},"555":{"body":146,"breadcrumbs":5,"title":1},"556":{"body":12,"breadcrumbs":6,"title":2},"557":{"body":12,"breadcrumbs":6,"title":2},"558":{"body":12,"breadcrumbs":6,"title":2},"559":{"body":12,"breadcrumbs":7,"title":3},"56":{"body":17,"breadcrumbs":8,"title":3},"560":{"body":12,"breadcrumbs":7,"title":3},"561":{"body":12,"breadcrumbs":7,"title":3},"562":{"body":17,"breadcrumbs":6,"title":2},"563":{"body":16,"breadcrumbs":6,"title":2},"564":{"body":47,"breadcrumbs":5,"title":1},"565":{"body":0,"breadcrumbs":6,"title":2},"566":{"body":25,"breadcrumbs":7,"title":3},"567":{"body":37,"breadcrumbs":6,"title":2},"568":{"body":17,"breadcrumbs":6,"title":2},"569":{"body":48,"breadcrumbs":6,"title":3},"57":{"body":19,"breadcrumbs":9,"title":4},"570":{"body":73,"breadcrumbs":4,"title":1},"571":{"body":194,"breadcrumbs":6,"title":3},"572":{"body":113,"breadcrumbs":5,"title":2},"573":{"body":0,"breadcrumbs":7,"title":4},"574":{"body":356,"breadcrumbs":4,"title":1},"575":{"body":393,"breadcrumbs":4,"title":1},"576":{"body":21,"breadcrumbs":5,"title":2},"577":{"body":7,"breadcrumbs":6,"title":3},"578":{"body":9,"breadcrumbs":8,"title":5},"579":{"body":125,"breadcrumbs":5,"title":2},"58":{"body":134,"breadcrumbs":9,"title":4},"580":{"body":63,"breadcrumbs":5,"title":2},"581":{"body":165,"breadcrumbs":3,"title":1},"582":{"body":78,"breadcrumbs":3,"title":1},"583":{"body":142,"breadcrumbs":6,"title":2},"584":{"body":69,"breadcrumbs":6,"title":2},"585":{"body":45,"breadcrumbs":7,"title":3},"586":{"body":0,"breadcrumbs":6,"title":2},"587":{"body":46,"breadcrumbs":9,"title":5},"588":{"body":50,"breadcrumbs":4,"title":1},"589":{"body":6,"breadcrumbs":4,"title":1},"59":{"body":92,"breadcrumbs":8,"title":3},"590":{"body":37,"breadcrumbs":5,"title":2},"591":{"body":121,"breadcrumbs":5,"title":2},"592":{"body":0,"breadcrumbs":5,"title":2},"593":{"body":43,"breadcrumbs":5,"title":2},"594":{"body":77,"breadcrumbs":5,"title":2},"595":{"body":41,"breadcrumbs":5,"title":2},"596":{"body":30,"breadcrumbs":5,"title":2},"597":{"body":21,"breadcrumbs":5,"title":2},"598":{"body":59,"breadcrumbs":6,"title":3},"599":{"body":25,"breadcrumbs":5,"title":2},"6":{"body":0,"breadcrumbs":2,"title":1},"60":{"body":121,"breadcrumbs":7,"title":2},"600":{"body":84,"breadcrumbs":5,"title":2},"601":{"body":28,"breadcrumbs":7,"title":4},"602":{"body":64,"breadcrumbs":7,"title":4},"603":{"body":15,"breadcrumbs":5,"title":2},"604":{"body":62,"breadcrumbs":5,"title":2},"605":{"body":67,"breadcrumbs":5,"title":2},"606":{"body":0,"breadcrumbs":5,"title":2},"607":{"body":27,"breadcrumbs":5,"title":2},"608":{"body":20,"breadcrumbs":5,"title":2},"609":{"body":118,"breadcrumbs":4,"title":1},"61":{"body":35,"breadcrumbs":6,"title":1},"610":{"body":25,"breadcrumbs":4,"title":1},"611":{"body":141,"breadcrumbs":4,"title":1},"612":{"body":67,"breadcrumbs":6,"title":3},"613":{"body":50,"breadcrumbs":5,"title":2},"614":{"body":175,"breadcrumbs":5,"title":2},"615":{"body":31,"breadcrumbs":5,"title":2},"616":{"body":11,"breadcrumbs":5,"title":2},"617":{"body":45,"breadcrumbs":4,"title":1},"618":{"body":9,"breadcrumbs":5,"title":2},"619":{"body":21,"breadcrumbs":5,"title":2},"62":{"body":132,"breadcrumbs":6,"title":1},"620":{"body":20,"breadcrumbs":5,"title":2},"621":{"body":17,"breadcrumbs":5,"title":2},"622":{"body":26,"breadcrumbs":9,"title":6},"623":{"body":464,"breadcrumbs":4,"title":1},"624":{"body":4,"breadcrumbs":4,"title":1},"625":{"body":31,"breadcrumbs":4,"title":1},"626":{"body":71,"breadcrumbs":4,"title":1},"627":{"body":85,"breadcrumbs":4,"title":1},"628":{"body":25,"breadcrumbs":4,"title":1},"629":{"body":49,"breadcrumbs":5,"title":2},"63":{"body":8,"breadcrumbs":7,"title":2},"630":{"body":4,"breadcrumbs":4,"title":1},"631":{"body":25,"breadcrumbs":4,"title":1},"632":{"body":6,"breadcrumbs":4,"title":1},"633":{"body":108,"breadcrumbs":5,"title":2},"634":{"body":113,"breadcrumbs":5,"title":2},"635":{"body":17,"breadcrumbs":5,"title":2},"636":{"body":34,"breadcrumbs":4,"title":1},"637":{"body":4,"breadcrumbs":4,"title":1},"638":{"body":34,"breadcrumbs":4,"title":1},"639":{"body":19,"breadcrumbs":4,"title":1},"64":{"body":17,"breadcrumbs":6,"title":1},"640":{"body":128,"breadcrumbs":4,"title":1},"641":{"body":34,"breadcrumbs":4,"title":1},"642":{"body":4,"breadcrumbs":4,"title":1},"643":{"body":110,"breadcrumbs":4,"title":1},"644":{"body":57,"breadcrumbs":4,"title":1},"645":{"body":53,"breadcrumbs":5,"title":2},"646":{"body":4,"breadcrumbs":4,"title":1},"647":{"body":19,"breadcrumbs":4,"title":1},"648":{"body":111,"breadcrumbs":4,"title":1},"649":{"body":40,"breadcrumbs":4,"title":1},"65":{"body":133,"breadcrumbs":6,"title":1},"650":{"body":83,"breadcrumbs":4,"title":1},"651":{"body":209,"breadcrumbs":4,"title":1},"652":{"body":1,"breadcrumbs":5,"title":2},"653":{"body":29,"breadcrumbs":4,"title":1},"654":{"body":39,"breadcrumbs":5,"title":2},"655":{"body":28,"breadcrumbs":5,"title":2},"656":{"body":21,"breadcrumbs":5,"title":2},"657":{"body":336,"breadcrumbs":5,"title":2},"658":{"body":25,"breadcrumbs":4,"title":1},"659":{"body":0,"breadcrumbs":5,"title":2},"66":{"body":81,"breadcrumbs":7,"title":2},"660":{"body":33,"breadcrumbs":7,"title":4},"661":{"body":31,"breadcrumbs":4,"title":1},"662":{"body":106,"breadcrumbs":5,"title":2},"663":{"body":78,"breadcrumbs":6,"title":3},"664":{"body":326,"breadcrumbs":4,"title":1},"665":{"body":26,"breadcrumbs":5,"title":2},"666":{"body":0,"breadcrumbs":5,"title":2},"667":{"body":113,"breadcrumbs":8,"title":5},"668":{"body":38,"breadcrumbs":5,"title":2},"669":{"body":58,"breadcrumbs":7,"title":2},"67":{"body":60,"breadcrumbs":8,"title":3},"670":{"body":1,"breadcrumbs":7,"title":2},"671":{"body":21,"breadcrumbs":6,"title":2},"672":{"body":36,"breadcrumbs":6,"title":2},"673":{"body":1,"breadcrumbs":6,"title":2},"674":{"body":102,"breadcrumbs":6,"title":3},"675":{"body":27,"breadcrumbs":5,"title":2},"676":{"body":36,"breadcrumbs":7,"title":4},"677":{"body":71,"breadcrumbs":6,"title":3},"678":{"body":1,"breadcrumbs":5,"title":2},"679":{"body":21,"breadcrumbs":6,"title":2},"68":{"body":54,"breadcrumbs":8,"title":3},"680":{"body":29,"breadcrumbs":5,"title":1},"681":{"body":0,"breadcrumbs":6,"title":2},"682":{"body":98,"breadcrumbs":5,"title":1},"683":{"body":54,"breadcrumbs":5,"title":1},"684":{"body":54,"breadcrumbs":5,"title":1},"685":{"body":83,"breadcrumbs":5,"title":1},"686":{"body":60,"breadcrumbs":5,"title":1},"687":{"body":0,"breadcrumbs":6,"title":2},"688":{"body":94,"breadcrumbs":7,"title":3},"689":{"body":156,"breadcrumbs":6,"title":2},"69":{"body":97,"breadcrumbs":8,"title":3},"690":{"body":58,"breadcrumbs":5,"title":2},"691":{"body":40,"breadcrumbs":5,"title":2},"692":{"body":53,"breadcrumbs":7,"title":4},"693":{"body":33,"breadcrumbs":6,"title":3},"694":{"body":8,"breadcrumbs":4,"title":1},"695":{"body":0,"breadcrumbs":4,"title":1},"696":{"body":105,"breadcrumbs":4,"title":1},"697":{"body":0,"breadcrumbs":4,"title":1},"698":{"body":136,"breadcrumbs":4,"title":1},"699":{"body":19,"breadcrumbs":4,"title":1},"7":{"body":47,"breadcrumbs":3,"title":2},"70":{"body":0,"breadcrumbs":7,"title":2},"700":{"body":0,"breadcrumbs":4,"title":1},"701":{"body":271,"breadcrumbs":5,"title":2},"702":{"body":0,"breadcrumbs":5,"title":2},"703":{"body":28,"breadcrumbs":5,"title":2},"704":{"body":76,"breadcrumbs":6,"title":2},"705":{"body":105,"breadcrumbs":6,"title":2},"706":{"body":70,"breadcrumbs":8,"title":4},"707":{"body":0,"breadcrumbs":6,"title":2},"708":{"body":43,"breadcrumbs":7,"title":3},"709":{"body":79,"breadcrumbs":7,"title":3},"71":{"body":79,"breadcrumbs":9,"title":4},"710":{"body":10,"breadcrumbs":5,"title":1},"711":{"body":10,"breadcrumbs":5,"title":1},"712":{"body":35,"breadcrumbs":5,"title":1},"713":{"body":106,"breadcrumbs":5,"title":1},"714":{"body":92,"breadcrumbs":6,"title":2},"715":{"body":0,"breadcrumbs":5,"title":1},"716":{"body":22,"breadcrumbs":7,"title":3},"717":{"body":98,"breadcrumbs":6,"title":2},"718":{"body":0,"breadcrumbs":6,"title":2},"719":{"body":92,"breadcrumbs":8,"title":4},"72":{"body":25,"breadcrumbs":11,"title":6},"720":{"body":30,"breadcrumbs":7,"title":3},"721":{"body":50,"breadcrumbs":7,"title":3},"722":{"body":22,"breadcrumbs":7,"title":3},"723":{"body":31,"breadcrumbs":7,"title":3},"724":{"body":15,"breadcrumbs":5,"title":2},"725":{"body":43,"breadcrumbs":4,"title":1},"726":{"body":147,"breadcrumbs":7,"title":4},"727":{"body":58,"breadcrumbs":5,"title":2},"728":{"body":27,"breadcrumbs":5,"title":2},"729":{"body":67,"breadcrumbs":5,"title":2},"73":{"body":63,"breadcrumbs":10,"title":5},"730":{"body":49,"breadcrumbs":4,"title":1},"731":{"body":161,"breadcrumbs":2,"title":1},"732":{"body":0,"breadcrumbs":3,"title":2},"733":{"body":9,"breadcrumbs":4,"title":3},"734":{"body":12,"breadcrumbs":4,"title":3},"735":{"body":62,"breadcrumbs":2,"title":1},"736":{"body":12,"breadcrumbs":2,"title":1},"737":{"body":34,"breadcrumbs":4,"title":3},"738":{"body":38,"breadcrumbs":4,"title":3},"739":{"body":13,"breadcrumbs":4,"title":3},"74":{"body":17,"breadcrumbs":11,"title":4},"740":{"body":27,"breadcrumbs":4,"title":3},"741":{"body":27,"breadcrumbs":4,"title":3},"742":{"body":45,"breadcrumbs":2,"title":1},"743":{"body":19,"breadcrumbs":3,"title":2},"744":{"body":34,"breadcrumbs":4,"title":3},"745":{"body":57,"breadcrumbs":4,"title":3},"746":{"body":33,"breadcrumbs":2,"title":1},"747":{"body":31,"breadcrumbs":2,"title":1},"748":{"body":50,"breadcrumbs":3,"title":2},"749":{"body":36,"breadcrumbs":3,"title":2},"75":{"body":122,"breadcrumbs":8,"title":1},"750":{"body":9,"breadcrumbs":3,"title":2},"751":{"body":80,"breadcrumbs":2,"title":1},"752":{"body":34,"breadcrumbs":3,"title":2},"753":{"body":41,"breadcrumbs":5,"title":4},"754":{"body":21,"breadcrumbs":4,"title":3},"755":{"body":20,"breadcrumbs":3,"title":2},"756":{"body":9,"breadcrumbs":3,"title":2},"757":{"body":15,"breadcrumbs":2,"title":1},"758":{"body":21,"breadcrumbs":4,"title":3},"759":{"body":46,"breadcrumbs":3,"title":2},"76":{"body":41,"breadcrumbs":9,"title":2},"760":{"body":53,"breadcrumbs":2,"title":1},"761":{"body":10,"breadcrumbs":2,"title":1},"762":{"body":30,"breadcrumbs":3,"title":2},"763":{"body":0,"breadcrumbs":3,"title":2},"764":{"body":48,"breadcrumbs":3,"title":2},"765":{"body":36,"breadcrumbs":4,"title":3},"766":{"body":54,"breadcrumbs":3,"title":2},"767":{"body":77,"breadcrumbs":2,"title":1},"768":{"body":22,"breadcrumbs":3,"title":2},"769":{"body":40,"breadcrumbs":2,"title":1},"77":{"body":18,"breadcrumbs":9,"title":2},"770":{"body":50,"breadcrumbs":3,"title":2},"771":{"body":105,"breadcrumbs":4,"title":3},"772":{"body":97,"breadcrumbs":3,"title":2},"773":{"body":0,"breadcrumbs":5,"title":4},"774":{"body":36,"breadcrumbs":2,"title":1},"775":{"body":20,"breadcrumbs":4,"title":3},"776":{"body":38,"breadcrumbs":4,"title":3},"777":{"body":29,"breadcrumbs":3,"title":2},"778":{"body":45,"breadcrumbs":3,"title":2},"779":{"body":121,"breadcrumbs":4,"title":3},"78":{"body":294,"breadcrumbs":10,"title":3},"780":{"body":21,"breadcrumbs":4,"title":3},"781":{"body":18,"breadcrumbs":4,"title":3},"782":{"body":10,"breadcrumbs":4,"title":3},"783":{"body":25,"breadcrumbs":4,"title":3},"784":{"body":10,"breadcrumbs":4,"title":3},"785":{"body":49,"breadcrumbs":4,"title":3},"786":{"body":21,"breadcrumbs":4,"title":3},"787":{"body":0,"breadcrumbs":4,"title":3},"788":{"body":17,"breadcrumbs":3,"title":2},"789":{"body":91,"breadcrumbs":3,"title":2},"79":{"body":79,"breadcrumbs":11,"title":4},"790":{"body":26,"breadcrumbs":3,"title":2},"791":{"body":22,"breadcrumbs":5,"title":4},"792":{"body":14,"breadcrumbs":4,"title":3},"793":{"body":7,"breadcrumbs":5,"title":4},"794":{"body":46,"breadcrumbs":2,"title":1},"795":{"body":14,"breadcrumbs":3,"title":2},"796":{"body":32,"breadcrumbs":3,"title":2},"797":{"body":36,"breadcrumbs":3,"title":2},"798":{"body":21,"breadcrumbs":3,"title":2},"799":{"body":0,"breadcrumbs":4,"title":3},"8":{"body":51,"breadcrumbs":3,"title":2},"80":{"body":79,"breadcrumbs":10,"title":3},"800":{"body":71,"breadcrumbs":3,"title":2},"81":{"body":23,"breadcrumbs":10,"title":5},"82":{"body":74,"breadcrumbs":6,"title":1},"83":{"body":36,"breadcrumbs":9,"title":4},"84":{"body":112,"breadcrumbs":7,"title":2},"85":{"body":128,"breadcrumbs":9,"title":4},"86":{"body":153,"breadcrumbs":10,"title":5},"87":{"body":17,"breadcrumbs":6,"title":1},"88":{"body":0,"breadcrumbs":7,"title":2},"89":{"body":36,"breadcrumbs":7,"title":2},"9":{"body":27,"breadcrumbs":3,"title":2},"90":{"body":81,"breadcrumbs":9,"title":3},"91":{"body":29,"breadcrumbs":8,"title":2},"92":{"body":34,"breadcrumbs":9,"title":3},"93":{"body":54,"breadcrumbs":9,"title":3},"94":{"body":16,"breadcrumbs":7,"title":1},"95":{"body":56,"breadcrumbs":8,"title":2},"96":{"body":22,"breadcrumbs":11,"title":5},"97":{"body":19,"breadcrumbs":11,"title":5},"98":{"body":419,"breadcrumbs":12,"title":6},"99":{"body":0,"breadcrumbs":8,"title":2}},"docs":{"0":{"body":"Table of Contents About Optimism About the OP Stack Site Navigation","breadcrumbs":"Introduction » OP Stack Specification","id":"0","title":"OP Stack Specification"},"1":{"body":"Optimism is a project dedicated to scaling Ethereum's technology and expanding its ability to coordinate people from across the world to build effective decentralized economies and governance systems. The Optimism Collective builds open-source software that powers scalable blockchains and aims to address key governance and economic challenges in the wider Ethereum ecosystem. Optimism operates on the principle of impact=profit , the idea that individuals who positively impact the Collective should be proportionally rewarded with profit. Change the incentives and you change the world.","breadcrumbs":"Introduction » About Optimism","id":"1","title":"About Optimism"},"10":{"body":"We strive to preserve three critical properties: liveness, validity, and availability. A protocol that can maintain these properties can, effectively, scale Ethereum without sacrificing security.","breadcrumbs":"Background » Protocol Guarantees","id":"10","title":"Protocol Guarantees"},"100":{"body":"This updates which L2 blocks the engine considers to be canonical (forkchoiceState argument), and optionally initiates block production (payloadAttributes argument). Within the rollup, the types of forkchoice updates translate as: headBlockHash: block hash of the head of the canonical chain. Labeled \"unsafe\" in user JSON-RPC. Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts. safeBlockHash: block hash of the canonical chain, derived from L1 data, unlikely to reorg. finalizedBlockHash: irreversible block hash, matches lower boundary of the dispute period. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV2 : the extended PayloadAttributesV2 Extended PayloadAttributesV2 PayloadAttributesV2 is extended to: PayloadAttributesV2: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The type notation used here refers to the HEX value encoding used by the Ethereum JSON-RPC API specification , as this structure will need to be sent over JSON-RPC. array refers to a JSON array. Each item of the transactions array is a byte list encoding a transaction: TransactionType || TransactionPayload or LegacyTransaction, as defined in EIP-2718 . This is equivalent to the transactions field in ExecutionPayloadV2 The transactions field is optional: If empty or missing: no changes to engine behavior. The sequencers will (if enabled) build a block by consuming transactions from the transaction pool. If present and non-empty: the payload MUST be produced starting with this exact list of transactions. The rollup driver determines the transaction list based on deterministic L1 inputs. The noTxPool is optional as well, and extends the transactions meaning: If false, the execution engine is free to pack additional transactions from external sources like the tx pool into the payload, after any of the transactions. This is the default behavior a L1 node implements. If true, the execution engine must not change anything about the given list of transactions. If the transactions field is present, the engine must execute the transactions in order and return STATUS_INVALID if there is an error processing the transactions. It must return STATUS_VALID if all of the transactions could be executed without error. Note : The state transition rules have been modified such that deposits will never fail so if engine_forkchoiceUpdatedV2 returns STATUS_INVALID it is because a batched transaction is invalid. The gasLimit is optional w.r.t. compatibility with L1, but required when used as rollup. This field overrides the gas limit used during block-building. If not specified as rollup, a STATUS_INVALID is returned.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV2","id":"100","title":"engine_forkchoiceUpdatedV2"},"101":{"body":"See engine_forkchoiceUpdatedV2 for a description of the forkchoice updated method. engine_forkchoiceUpdatedV3 must only be called with Ecotone payload. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV3 : the extended PayloadAttributesV3 Extended PayloadAttributesV3 PayloadAttributesV3 is extended to: PayloadAttributesV3: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 parentBeaconBlockRoot: DATA (32 bytes) transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The requirements of this object are the same as extended PayloadAttributesV2 with the addition of parentBeaconBlockRoot which is the parent beacon block root from the L1 origin block of the L2 block. Starting at Ecotone, the parentBeaconBlockRoot must be set to the L1 origin parentBeaconBlockRoot, or a zero bytes32 if the Dencun functionality with parentBeaconBlockRoot is not active on L1.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV3","id":"101","title":"engine_forkchoiceUpdatedV3"},"102":{"body":"No modifications to engine_newPayloadV2 . Applies a L2 block to the engine state.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV2","id":"102","title":"engine_newPayloadV2"},"103":{"body":"engine_newPayloadV3 applies an Ecotone L2 block to the engine state. There are no modifications to this API. engine_newPayloadV3 must only be called with Ecotone payload. The additional parameters should be set as follows: expectedBlobVersionedHashes MUST be an empty array. parentBeaconBlockRoot MUST be the parent beacon block root from the L1 origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV3","id":"103","title":"engine_newPayloadV3"},"104":{"body":"No modifications to engine_getPayloadV2 . Retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV2 when called with payloadAttributes.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV2","id":"104","title":"engine_getPayloadV2"},"105":{"body":"engine_getPayloadV3 retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV3 when called with payloadAttributes. engine_getPayloadV3 must only be called with Ecotone payload. Extended Response The response is extended to: { executionPayload: ExecutionPayload blockValue: QUANTITY blobsBundle: BlobsBundle shouldOverrideBuilder: BOOLEAN parentBeaconBlockRoot: DATA (32 bytes)\n} In Ecotone it MUST be set to the parentBeaconBlockRoot from the L1 Origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV3","id":"105","title":"engine_getPayloadV3"},"106":{"body":"Optional extension to the Engine API. Signals superchain information to the Engine: V1 signals which protocol version is recommended and required. Types: SuperchainSignal: { recommended: ProtocolVersion; required: ProtocolVersion;\n} ProtocolVersion: encoded for RPC as defined in Protocol Version format specification . Parameters: signal: SuperchainSignal, the signaled superchain information. Returns: ProtocolVersion: the latest supported OP-Stack protocol version of the execution engine. The execution engine SHOULD warn the user when the recommended version is newer than the current version supported by the execution engine. The execution engine SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the execution engine operator.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_signalSuperchainV1","id":"106","title":"engine_signalSuperchainV1"},"107":{"body":"The execution engine can acquire all data through the rollup node, as derived from L1: P2P networking is strictly optional. However, to not bottleneck on L1 data retrieval speed, the P2P network functionality SHOULD be enabled, serving: Peer discovery ( Disc v5 ) eth/66 : Transaction pool (consumed by sequencer nodes) State sync (happy-path for fast trustless db replication) Historical block header and body retrieval New blocks are acquired through the consensus layer instead (rollup node) No modifications to L1 network functionality are required, except configuration: networkID : Distinguishes the L2 network from L1 and testnets. Equal to the chainID of the rollup network. Activate Merge fork: Enables Engine API and disables propagation of blocks, as block headers cannot be authenticated without consensus layer. Bootnode list: DiscV5 is a shared network, bootstrap is faster through connecting with L2 nodes first.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Networking","id":"107","title":"Networking"},"108":{"body":"The execution engine can operate sync in different ways: Happy-path: rollup node informs engine of the desired chain head as determined by L1, completes through engine P2P. Worst-case: rollup node detects stalled engine, completes sync purely from L1 data, no peers required. The happy-path is more suitable to bring new nodes online quickly, as the engine implementation can sync state faster through methods like snap-sync .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Sync","id":"108","title":"Sync"},"109":{"body":"The rollup node informs the engine of the L2 chain head, unconditionally (part of regular node operation): Bedrock / Canyon / Delta Payloads engine_newPayloadV2 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV2 is called with the current unsafe/safe/finalized L2 block hashes. Ecotone Payloads engine_newPayloadV3 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV3 is called with the current unsafe/safe/finalized L2 block hashes. The engine requests headers from peers, in reverse till the parent hash matches the local chain The engine catches up: a) A form of state sync is activated towards the finalized or head block hash b) A form of block sync pulls block bodies and processes towards head block hash The exact P2P based sync is out of scope for the L2 specification: the operation within the engine is the exact same as with L1 (although with an EVM that supports deposits).","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Happy-path sync","id":"109","title":"Happy-path sync"},"11":{"body":"Liveness is defined as the ability for any party to be able to extend the rollup chain by including a transaction within a bounded amount of time. It should not be possible for an actor to block the inclusion of any given transaction for more than this bounded time period. This bounded time period should also be acceptable such that inclusion is not just theoretically possible but practically useful.","breadcrumbs":"Background » Liveness","id":"11","title":"Liveness"},"110":{"body":"Engine is out of sync, not peered and/or stalled due other reasons. The rollup node maintains latest head from engine (poll eth_getBlockByNumber and/or maintain a header subscription) The rollup node activates sync if the engine is out of sync but not syncing through P2P (eth_syncing) The rollup node inserts blocks, derived from L1, one by one, potentially adapting to L1 reorg(s), as outlined in the rollup node spec .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Worst-case sync","id":"110","title":"Worst-case sync"},"111":{"body":"EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction, plus a list of \"blobs\": \"Binary Large Object\", i.e. a dedicated data type for serving Data-Availability as base-layer. With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception: as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type. EIP-4844 is disabled as following: Transaction network-layer announcements, announcing blob-type transactions, are ignored. Transactions of the blob-type, through the RPC or otherwise, are not allowed into the transaction pool. Block-building code does not select EIP-4844 transactions. An L2 block state-transition with EIP-4844 transactions is invalid. The BLOBBASEFEE opcode is present but its semantics are altered because there are no blobs processed by L2. The opcode will always push a value of 1 onto the stack.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: disable Blob-transactions","id":"111","title":"Ecotone: disable Blob-transactions"},"112":{"body":"EIP-4788 introduces a \"beacon block root\" into the execution-layer block-header and EVM. This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block. With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO of L1. And thus with EIP-4788 the L1 beacon block root is made available. For the Ecotone upgrade, this entails that: The parent_beacon_block_root of the L1 origin is now embedded in the L2 block header. The \"Beacon roots contract\" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis. The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: Beacon Block Root","id":"112","title":"Ecotone: Beacon Block Root"},"113":{"body":"The Ethereum Node Record (ENR) for an Optimism execution node must contain an opel key-value pair where the key is opel and the value is a EIP-2124 fork id. The EL uses a different key from the CL in order to stop EL and CL nodes from connecting to each other.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » P2P Modifications","id":"113","title":"P2P Modifications"},"114":{"body":"Table of Contents Overview Driver Derivation L2 Output RPC method Structures BlockID L1BlockRef L2BlockRef SyncStatus Output Method API Protocol Version tracking","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node Specification","id":"114","title":"Rollup Node Specification"},"115":{"body":"The rollup node is the component responsible for deriving the L2 chain from L1 blocks (and their associated receipts ). The part of the rollup node that derives the L2 chain is called the rollup driver . This document is currently only concerned with the specification of the rollup driver.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Overview","id":"115","title":"Overview"},"116":{"body":"The task of the driver in the rollup node is to manage the derivation process: Keep track of L1 head block Keep track of the L2 chain sync progress Iterate over the derivation steps as new inputs become available","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Driver","id":"116","title":"Driver"},"117":{"body":"This process happens in three steps: Select inputs from the L1 chain, on top of the last L2 block: a list of blocks, with transactions and associated data and receipts. Read L1 information, deposits, and sequencing batches in order to generate payload attributes (essentially a block without output properties ). Pass the payload attributes to the execution engine , so that the L2 block (including output block properties ) may be computed. While this process is conceptually a pure function from the L1 chain to the L2 chain, it is in practice incremental. The L2 chain is extended whenever new L1 blocks are added to the L1 chain. Similarly, the L2 chain re-organizes whenever the L1 chain re-organizes . For a complete specification of the L2 block derivation, refer to the L2 block derivation document .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation","id":"117","title":"Derivation"},"118":{"body":"The Rollup node has its own RPC method, optimism_outputAtBlock which returns a 32 byte hash corresponding to the L2 output root .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » L2 Output RPC method","id":"118","title":"L2 Output RPC method"},"119":{"body":"These define the types used by rollup node API methods. The types defined here are extended from the engine API specs . BlockID hash: DATA, 32 Bytes number: QUANTITY, 64 Bits L1BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits L2BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits l1origin: BlockID sequenceNumber: QUANTITY, 64 Bits - distance to first block of epoch SyncStatus Represents a snapshot of the rollup driver. current_l1: Object - instance of L1BlockRef . current_l1_finalized: Object - instance of L1BlockRef . head_l1: Object - instance of L1BlockRef . safe_l1: Object - instance of L1BlockRef . finalized_l1: Object - instance of L1BlockRef . unsafe_l2: Object - instance of L2BlockRef . safe_l2: Object - instance of L2BlockRef . finalized_l2: Object - instance of L2BlockRef . pending_safe_l2: Object - instance of L2BlockRef . queued_unsafe_l2: Object - instance of L2BlockRef .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Structures","id":"119","title":"Structures"},"12":{"body":"Validity is defined as the ability for any party to execute the rollup state transition function, subject to certain lower bound expectations for available computing and bandwidth resources. Validity is also extended to refer to the ability for a smart contract on Ethereum to be able to validate this state transition function economically.","breadcrumbs":"Background » Validity","id":"12","title":"Validity"},"120":{"body":"The input and return types here are as defined by the engine API specs . method: optimism_outputAtBlock params: blockNumber: QUANTITY, 64 bits - L2 integer block number. returns: version: DATA, 32 Bytes - the output root version number, beginning with 0. outputRoot: DATA, 32 Bytes - the output root. blockRef: Object - instance of L2BlockRef . withdrawalStorageRoot: 32 bytes - storage root of the L2toL1MessagePasser contract. stateRoot: DATA: 32 bytes - the state root. syncStatus: Object - instance of SyncStatus .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Output Method API","id":"120","title":"Output Method API"},"121":{"body":"The rollup-node should monitor the recommended and required protocol version by monitoring the Protocol Version contract on L1, as specified in the Superchain Version Signaling specifications . This can be implemented through polling in the Driver loop. After polling the Protocol Version, the rollup node SHOULD communicate it with the execution-engine through an engine_signalSuperchainV1 call. The rollup node SHOULD warn the user when the recommended version is newer than the current version supported by the rollup node. The rollup node SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the rollup node operator.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Protocol Version tracking","id":"121","title":"Protocol Version tracking"},"122":{"body":"Table of Contents Overview P2P configuration Identification Discv5 Consensus Layer Structure LibP2P Transport Dialing NAT Peer management Transport security Protocol negotiation Identify Ping Multiplexing GossipSub Content-based message identification Message compression and limits Message ID computation Heartbeat and parameters Topic configuration Topic validation Gossip Topics blocksv1 blocksv2 blocksv3 Block encoding Block signatures Block validation Block processing Block topic scoring parameters Req-Resp payload_by_number","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Rollup-node P2P interface","id":"122","title":"Rollup-node P2P interface"},"123":{"body":"The rollup node has an optional peer-to-peer (P2P) network service to improve the latency between the view of sequencers and the rest of the network by bypassing the L1 in the happy case, without relying on a single centralized endpoint. This also enables faster historical sync to be bootstrapped by providing block headers to sync towards, and only having to compare the L2 chain inputs to the L1 data as compared to processing everything one block at a time. The rollup node will always prioritize L1 and reorganize to match the canonical chain. The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the \"unsafe\" chain, to improve the happy case performance. This also means that P2P behavior is a soft-rule: nodes keep each other in check with scoring and eventual banning of malicious peers by identity or IP. Any behavior on the P2P layer does not affect the rollup security, at worst nodes rely on higher-latency data from L1 to serve. In summary, the P2P stack looks like: Discovery to find peers: Discv5 Connections, peering, transport security, multiplexing, gossip: LibP2P Application-layer publishing and validation of gossiped messages like L2 blocks. This document only specifies the composition and configuration of these network libraries. These components have their own standards, implementations in Go/Rust/Java/Nim/JS/more, and are adopted by several other blockchains, most notably the L1 consensus layer (Eth2) .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Overview","id":"123","title":"Overview"},"124":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » P2P configuration","id":"124","title":"P2P configuration"},"125":{"body":"Nodes have a separate network- and consensus-identity. The network identity is a secp256k1 key, used for both discovery and active LibP2P connections. Common representations of network identity: PeerID: a LibP2P specific ID derived from the pubkey (through protobuf encoding, typing and hashing) NodeID: a Discv5 specific ID derived from the pubkey (through hashing, used in the DHT) Multi-address: an unsigned address, containing: IP, TCP port, PeerID ENR: a signed record used for discovery, containing: IP, TCP port, UDP port, signature (pubkey can be derived) and L2 network identification. Generally encoded in base64.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Identification","id":"125","title":"Identification"},"126":{"body":"Consensus Layer Structure The Ethereum Node Record (ENR) for an Optimism rollup node must contain the following values, identified by unique keys: An IPv4 address (ip field) and/or IPv6 address (ip6 field). A TCP port (tcp field) representing the local libp2p listening port. A UDP port (udp field) representing the local discv5 listening port. An OpStack (opstack field) L2 network identifier The opstack value is encoded as a single RLP bytes value, the concatenation of: chain ID (unsigned varint) fork ID (unsigned varint) Note that DiscV5 is a shared DHT (Distributed Hash Table): the L1 consensus and execution nodes, as well as testnet nodes, and even external IOT nodes, all communicate records in this large common DHT. This makes it more difficult to censor the discovery of node records. The discovery process in Optimism is a pipeline of node records: Fill the table with FINDNODES if necessary (Performed by Discv5 library) Pull additional records with searches to random Node IDs if necessary (e.g. iterate RandomNodes() in Go implementation) Pull records from the DiscV5 module when looking for peers Check if the record contains the opstack entry, verify it matches the chain ID and current or future fork number If not already connected, and not recently disconnected or put on deny-list, attempt to dial.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Discv5","id":"126","title":"Discv5"},"127":{"body":"Transport TCP transport. Additional transports are supported by LibP2P, but not required. Dialing Nodes should be publicly dialable, not rely on relay extensions, and able to dial both IPv4 and IPv6. NAT The listening endpoint must be publicly facing, but may be configured behind a NAT. LibP2P will use PMP / UPNP based techniques to track the external IP of the node. It is recommended to disable the above if the external IP is static and configured manually. Peer management The default is to maintain a peer count with a tide-system based on active peer count: At \"low tide\" the node starts to actively search for additional peer connections. At \"high tide\" the node starts to prune active connections, except those that are marked as trusted or have a grace period. Peers will have a grace period for a configurable amount of time after joining. In an emergency, when memory runs low, the node should start pruning more aggressively. Peer records can be persisted to disk to quickly reconnect with known peers after restarting the rollup node. The discovery process feeds the peerstore with peer records to connect to, tagged with a time-to-live (TTL). The current P2P processes do not require selective topic-specific peer connections, other than filtering for the basic network participation requirement. Peers may be banned if their performance score is too low, or if an objectively malicious action was detected. Banned peers will be persisted to the same data-store as the peerstore records. TODO: the connection gater does currently not gate by IP address on the dial Accept-callback. Transport security Libp2p-noise , XX handshake, with the secp256k1 P2P identity, as popularized in Eth2. The TLS option is available as well, but noise should be prioritized in negotiation. Protocol negotiation Multistream-select 1.0 (/multistream/1.0.0) is an interactive protocol used to negotiate sub-protocols supported in LibP2P peers. Multistream-select 2.0 may be used in the future. Identify LibP2P offers a minimal identification module to share client version and programming language. This is optional and can be disabled for enhanced privacy. It also includes the same protocol negotiation information, which can speed up initial connections. Ping LibP2P includes a simple ping protocol to track latency between connections. This should be enabled to help provide insight into the network health. Multiplexing For async communication over different channels over the same connection, multiplexing is used. mplex (/mplex/6.7.0) is required, and yamux (/yamux/1.0.0) is recommended but optional GossipSub GossipSub 1.1 (/meshsub/1.1.0, i.e. with peer-scoring extension) is a pubsub protocol for mesh-networks, deployed on L1 consensus (Eth2) and other protocols such as Filecoin, offering lots of customization options. Content-based message identification Messages are deduplicated, and filtered through application-layer signature verification. Thus origin-stamping is disabled and published messages must only contain application data, enforced through a StrictNoSign Signature Policy This provides greater privacy, and allows sequencers (consensus identity) to maintain multiple network identities for redundancy. Message compression and limits The application contents are compressed with snappy single-block-compression (as opposed to frame-compression), and constrained to 10 MiB. Message ID computation Same as L1 , with recognition of compression: If message.data has a valid snappy decompression, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_VALID_SNAPPY with the snappy decompressed message data, i.e. SHA256(MESSAGE_DOMAIN_VALID_SNAPPY + snappy_decompress(message.data))[:20]. Otherwise, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_INVALID_SNAPPY with the raw message data, i.e. SHA256(MESSAGE_DOMAIN_INVALID_SNAPPY + message.data)[:20]. Heartbeat and parameters GossipSub parameters : D (topic stable mesh target count): 8 D_low (topic stable mesh low watermark): 6 D_high (topic stable mesh high watermark): 12 D_lazy (gossip target): 6 heartbeat_interval (interval of heartbeat, in seconds): 0.5 fanout_ttl (ttl for fanout maps for topics we are not subscribed to but have published to, in seconds): 24 mcache_len (number of windows to retain full messages in cache for IWANT responses): 12 mcache_gossip (number of windows to gossip about): 3 seen_ttl (number of heartbeat intervals to retain message IDs): 130 (= 65 seconds) Notable differences from L1 consensus (Eth2): seen_ttl does not need to cover a full L1 epoch (6.4 minutes), but rather just a small window covering latest blocks fanout_ttl: adjusted to lower than seen_ttl mcache_len: a larger number of heartbeats can be retained since the gossip is much less noisy. heartbeat_interval: faster interval to reduce latency, bandwidth should still be reasonable since there are far fewer messages to gossip about each interval than on L1 which uses an interval of 0.7 seconds. Topic configuration Topics have string identifiers and are communicated with messages and subscriptions. /optimism/chain_id/hardfork_version/Name chain_id: replace with decimal representation of chain ID hardfork_version: replace with decimal representation of hardfork, starting at 0 Name: topic application-name Note that the topic encoding depends on the topic, unlike L1, since there are less topics, and all are snappy-compressed. Topic validation To ensure only valid messages are relayed, and malicious peers get scored based on application behavior, an extended validator checks the message before it is relayed or processed. The extended validator emits one of the following validation signals: ACCEPT valid, relayed to other peers and passed to local topic subscriber IGNORE scored like inactivity, message is dropped and not processed REJECT score penalties, message is dropped","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » LibP2P","id":"127","title":"LibP2P"},"128":{"body":"There are three topics for distributing blocks to other nodes faster than proxying through L1 would. These are:","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Gossip Topics","id":"128","title":"Gossip Topics"},"129":{"body":"Pre-Canyon/Shanghai blocks are broadcast on /optimism//0/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv1","id":"129","title":"blocksv1"},"13":{"body":"Availability is defined as the ability for any party to retrieve the inputs that are necessary to execute the rollup state transition function correctly. Availability is essentially an element of validity and is required to be able to guarantee validity in general. Similar to validity, availability is subject to lower bound resource requirements.","breadcrumbs":"Background » Availability","id":"13","title":"Availability"},"130":{"body":"Canyon/Delta blocks are broadcast on /optimism//1/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv2","id":"130","title":"blocksv2"},"131":{"body":"Ecotone blocks are broadcast on /optimism//2/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv3","id":"131","title":"blocksv3"},"132":{"body":"A block is structured as the concatenation of: V1 and V2 topics signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. V3 topic signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) parentBeaconBlockRoot: L1 origin parent beacon block root, always 32 bytes payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. All topics use Snappy block-compression (i.e. no snappy frames): the above needs to be compressed after encoding, and decompressed before decoding.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block encoding","id":"132","title":"Block encoding"},"133":{"body":"The signature is a secp256k1 signature, and signs over a message: keccak256(domain ++ chain_id ++ payload_hash), where: domain is 32 bytes, reserved for message types and versioning info. All zero for this signature. chain_id is a big-endian encoded uint256. payload_hash is keccak256(payload), where payload is the payload in V1 and V2, and parentBeaconBlockRoot ++ payload in V3. The secp256k1 signature must have y_parity = 1 or 0, the chain_id is already signed over.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block signatures","id":"133","title":"Block signatures"},"134":{"body":"An extended-validator checks the incoming messages as follows, in order of operation: [REJECT] if the compression is not valid [REJECT] if the block encoding is not valid [REJECT] if the payload.timestamp is older than 60 seconds in the past (graceful boundary for worst-case propagation and clock skew) [REJECT] if the payload.timestamp is more than 5 seconds into the future [REJECT] if the block_hash in the payload is not valid [REJECT] if the block is on the V1 topic and has withdrawals [REJECT] if the block is on the V1 topic and has a withdrawals list [REJECT] if the block is on a topic >= V2 and does not have an empty withdrawals list [REJECT] if the block is on a topic <= V2 and has a blob gas-used value set [REJECT] if the block is on a topic <= V2 and has an excess blob gas value set [REJECT] if the block is on a topic >= V3 and has a blob gas-used value that is not zero [REJECT] if the block is on a topic >= V3 and has an excess blob gas value that is not zero [REJECT] if the block is on a topic <= V2 and the parent beacon block root is not nil [REJECT] if the block is on a topic >= V3 and the parent beacon block root is nil [REJECT] if more than 5 different blocks have been seen with the same block height [IGNORE] if the block has already been seen [REJECT] if the signature by the sequencer is not valid Mark the block as seen for the given block height The block is signed by the corresponding sequencer, to filter malicious messages. The sequencer model is singular but may change to multiple sequencers in the future. A default sequencer pubkey is distributed with rollup nodes and should be configurable. Note that blocks that a block may still be propagated even if the L1 already confirmed a different block. The local L1 view of the node may be wrong, and the time and signature validation will prevent spam. Hence, calling into the execution engine with a block lookup every propagation step is not worth the added delay. Block processing A node may apply the block to their local engine ahead of L1 availability, if it ensures that: The application of the block is reversible, in case of a conflict with delayed L1 information The subsequent forkchoice-update ensures this block is recognized as \"unsafe\" (see fork choice updated ) Block topic scoring parameters TODO: GossipSub per-topic scoring to fine-tune incentives for ideal propagation delay and bandwidth usage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block validation","id":"134","title":"Block validation"},"135":{"body":"The op-node implements a similar request-response encoding for its sync protocols as the L1 ethereum Beacon-Chain. See L1 P2P-interface req-resp specification and Altair P2P update . However, the protocol is simplified, to avoid several issues seen in L1: Error strings in responses, if there is any alternative response, should not need to be compressed or have an artificial global length limit. Payload lengths should be fixed-length: byte-by-byte uvarint reading from the underlying stream is undesired. are relaxed to encode a uint32, rather than a beacon-chain ForkDigest. Payload-encoding may change per hardfork, so is not part of the protocol-ID. Usage of response-chunks is specific to the req-resp method: most basic req-resp does not need chunked responses. Compression is encouraged to be part of the payload-encoding, specific to the req-resp method, where necessary: pings and such do not need streaming frame compression etc. And the protocol ID format follows the same scheme as L1, except the trailing encoding schema part, which is now message-specific: /ProtocolPrefix/MessageName/SchemaVersion/ The req-resp protocols served by the op-node all have /ProtocolPrefix set to /opstack/req. Individual methods may include the chain ID as part of the /MessageName segment, so it's immediately clear which chain the method applies to, if the communication is chain-specific. Other methods may include chain-information in the request and/or response data, such as the ForkDigest in L1 beacon chain req-resp protocols. Each segment starts with a /, and may contain multiple /, and the final protocol ID is suffixed with a /.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Req-Resp","id":"135","title":"Req-Resp"},"136":{"body":"This is an optional chain syncing method, to request/serve execution payloads by number. This serves as a method to fill gaps upon missed gossip, and sync short to medium ranges of unsafe L2 blocks. Protocol ID: /opstack/req/payload_by_number//0/ /MessageName is /block_by_number/ where is set to the op-node L2 chain ID. /SchemaVersion is /0 Request format: : a little-endian uint64 - the block number to request. Response format: = is a byte code describing the result. 0 on success, should follow. 1 if valid request, but unavailable payload. 2 if invalid request 3+ if other error The >= 128 range is reserved for future use. is a little-endian uint32, identifying the response type (fork-specific) is an encoded block, read till stream EOF. The input of should be limited, as well as any generated decompressed output, to avoid unexpected resource usage or zip-bomb type attacks. A 10 MB limit is recommended, to ensure all blocks may be synced. Implementations may opt for a different limit, since this sync method is optional. list: 0: SSZ-encoded ExecutionPayload, with Snappy framing compression, matching the ExecutionPayload SSZ definition of the L1 Merge, L2 Bedrock and L2 Regolith, L2 Canyon versions. 1: SSZ-encoded ExecutionPayloadEnvelope with Snappy framing compression, matching the ExecutionPayloadEnvelope SSZ definition of the L2 Ecotone version. The request is by block-number, enabling parallel fetching of a chain across many peers. A res = 0 response should be verified to: Have a block-number matching the requested block number. Have a consistent blockhash w.r.t. the other block contents. Build towards a known canonical block. This can be verified by checking if the parent-hash of a previous trusted canonical block matches that of the verified hash of the retrieved block. For unsafe blocks this may be relaxed to verification against the parent-hash of any previously trusted block: The gossip validation process limits the amount of blocks that may be trusted to sync towards. The unsafe blocks should be queued for processing, the latest received L2 unsafe blocks should always override any previous chain, until the final L2 chain can be reproduced from L1 data. A res > 0 response code should not be accepted. The result code is helpful for debugging, but the client should regard any error like any other unanswered request, as the responding peer cannot be trusted.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » payload_by_number","id":"136","title":"payload_by_number"},"137":{"body":"Table of Contents Overview Eager Block Derivation Protocol Parameters Batch Submission Sequencing & Batch Submission Overview Batch Submission Wire Format Batcher Transaction Format Frame Format Channel Format Batch Format Architecture L2 Chain Derivation Pipeline L1 Traversal L1 Retrieval Frame Queue Channel Bank Pruning Timeouts Reading Loading frames Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue Engine API usage Bedrock, Canyon, Delta: API Usage Ecotone: API Usage Forkchoice synchronization L1-consolidation: payload attributes matching L1-sync: payload attributes processing Processing unsafe payload attributes Resetting the Pipeline Finding the sync starting point Resetting derivation stages About reorgs Post-Merge Deriving Payload Attributes Deriving the Transaction List Network upgrade automation transactions Ecotone L1Block Deployment GasPriceOracle Deployment L1Block Proxy Update GasPriceOracle Proxy Update GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) Building Individual Payload Attributes","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Specification","id":"137","title":"L2 Chain Derivation Specification"},"138":{"body":"Note the following assumes a single sequencer and batcher. In the future, the design will be adapted to accommodate multiple such entities. L2 chain derivation — deriving L2 blocks from L1 data — is one of the main responsibilities of the rollup node , both in validator mode, and in sequencer mode (where derivation acts as a sanity check on sequencing, and enables detecting L1 chain re-organizations ). The L2 chain is derived from the L1 chain. In particular, each L1 block following L2 chain inception is mapped to a sequencing epoch comprising at least one L2 block. Each L2 block belongs to exactly one epoch, and we call the corresponding L1 block its L1 origin . The epoch's number equals that of its L1 origin block. To derive the L2 blocks of epoch number E, we need the following inputs: L1 blocks in the range [E, E + SWS), called the sequencing window of the epoch, and SWS the sequencing window size. (Note that sequencing windows overlap.) Batcher transactions from blocks in the sequencing window. These transactions allow us to reconstruct the epoch's sequencer batches , each of which will produce one L2 block. Note that: The L1 origin will never contain any data needed to construct sequencer batches since each batch must contain the L1 origin hash. An epoch may have no sequencer batches. Deposits made in the L1 origin (in the form of events emitted by the deposit contract ). L1 block attributes from the L1 origin (to derive the L1 attributes deposited transaction ). The state of the L2 chain after the last L2 block of the previous epoch, or the L2 genesis state if E is the first epoch. To derive the whole L2 chain from scratch, we start with the L2 genesis state and the L2 genesis block as the first L2 block. We then derive L2 blocks from each epoch in order, starting at the first L1 block following L2 chain inception . Refer to the Architecture section for more information on how we implement this in practice. The L2 chain may contain pre-Bedrock history, but the L2 genesis here refers to the Bedrock L2 genesis block. Each L2 block with origin l1_origin is subject to the following constraints (whose values are denominated in seconds): block.timestamp = prev_l2_timestamp + l2_block_time prev_l2_timestamp is the timestamp of the L2 block immediately preceding this one. If there is no preceding block, then this is the genesis block, and its timestamp is explicitly specified. l2_block_time is a configurable parameter of the time between L2 blocks (2s on Optimism). l1_origin.timestamp <= block.timestamp <= max_l2_timestamp, where max_l2_timestamp = max(l1_origin.timestamp + max_sequencer_drift, prev_l2_timestamp + l2_block_time) max_sequencer_drift is a configurable parameter that bounds how far the sequencer can get ahead of the L1. Finally, each epoch must have at least one L2 block. The first constraint means there must be an L2 block every l2_block_time seconds following L2 chain inception. The second constraint ensures that an L2 block timestamp never precedes its L1 origin timestamp, and is never more than max_sequencer_drift ahead of it, except only in the unusual case where it might prohibit an L2 block from being produced every l2_block_time seconds. (Such cases might arise for example under a proof-of-work L1 that sees a period of rapid L1 block production.) In either case, the sequencer enforces len(batch.transactions) == 0 while max_sequencer_drift is exceeded. See Batch Queue for more details. The final requirement that each epoch must have at least one L2 block ensures that all relevant information from the L1 (e.g. deposits) is represented in the L2, even if it has no sequencer batches. Post-merge, Ethereum has a fixed 12s block time , though some slots can be skipped. Under a 2s L2 block time, we thus expect each epoch to typically contain 12/2 = 6 L2 blocks. The sequencer will however produce bigger epochs in order to maintain liveness in case of either a skipped slot on the L1 or a temporary loss of connection to it. For the lost connection case, smaller epochs might be produced after the connection was restored to keep L2 timestamps from drifting further and further ahead.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Overview","id":"138","title":"Overview"},"139":{"body":"Deriving an L2 block requires that we have constructed its sequencer batch and derived all L2 blocks and state updates prior to it. This means we can typically derive the L2 blocks of an epoch eagerly without waiting on the full sequencing window. The full sequencing window is required before derivation only in the very worst case where some portion of the sequencer batch for the first block of the epoch appears in the very last L1 block of the window. Note that this only applies to block derivation. Sequencer batches can still be derived and tentatively queued without deriving blocks from them.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Eager Block Derivation","id":"139","title":"Eager Block Derivation"},"14":{"body":"Generally speaking, there are three primary actors that interact with an OP Stack chain: users, sequencers, and verifiers. graph TD EthereumL1(Ethereum L1) subgraph \"L2 Participants\" Users(Users) Sequencers(Sequencers) Verifiers(Verifiers) end Verifiers -.->|fetch transaction batches| EthereumL1 Verifiers -.->|fetch deposit data| EthereumL1 Verifiers -->|submit/validate/challenge output proposals| EthereumL1 Verifiers -.->|fetch realtime P2P updates| Sequencers Users -->|submit deposits/withdrawals| EthereumL1 Users -->|submit transactions| Sequencers Users -->|query data| Verifiers Sequencers -->|submit transaction batches| EthereumL1 Sequencers -.->|fetch deposit data| EthereumL1 classDef l1Contracts stroke:#bbf,stroke-width:2px; classDef l2Components stroke:#333,stroke-width:2px; classDef systemUser stroke:#f9a,stroke-width:2px; class EthereumL1 l1Contracts; class Users,Sequencers,Verifiers l2Components;","breadcrumbs":"Background » Network Participants","id":"14","title":"Network Participants"},"140":{"body":"The following table gives an overview of some protocol parameters, and how they are affected by protocol upgrades. Parameter Bedrock (default) value Latest (default) value Changes Notes max_sequencer_drift 600 1800 Fjord Changed from a chain parameter to a constant with Fjord. MAX_RLP_BYTES_PER_CHANNEL 10,000,000 100,000,000 Fjord Constant increased with Fjord. MAX_CHANNEL_BANK_SIZE 100,000,000 1,000,000,000 Fjord Constant increased with Fjord. MAX_SPAN_BATCH_ELEMENT_COUNT 10,000,000 10,000,000 Effectively introduced in Fjord Number of elements","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Protocol Parameters","id":"140","title":"Protocol Parameters"},"141":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission","id":"141","title":"Batch Submission"},"142":{"body":"The sequencer accepts L2 transactions from users. It is responsible for building blocks out of these. For each such block, it also creates a corresponding sequencer batch . It is also responsible for submitting each batch to a data availability provider (e.g. Ethereum calldata), which it does via its batcher component. The difference between an L2 block and a batch is subtle but important: the block includes an L2 state root, whereas the batch only commits to transactions at a given L2 timestamp (equivalently: L2 block number). A block also includes a reference to the previous block (*). (*) This matters in some edge case where a L1 reorg would occur and a batch would be reposted to the L1 chain but not the preceding batch, whereas the predecessor of an L2 block cannot possibly change. This means that even if the sequencer applies a state transition incorrectly, the transactions in the batch will still be considered part of the canonical L2 chain. Batches are still subject to validity checks (i.e. they have to be encoded correctly), and so are individual transactions within the batch (e.g. signatures have to be valid). Invalid batches and invalid individual transactions within an otherwise valid batch are discarded by correct nodes. If the sequencer applies a state transition incorrectly and posts an output root , then this output root will be incorrect. The incorrect output root will be challenged by a fault proof , then replaced by a correct output root for the existing sequencer batches. Refer to the Batch Submission specification for more information.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Sequencing & Batch Submission Overview","id":"142","title":"Sequencing & Batch Submission Overview"},"143":{"body":"Batch submission is closely tied to L2 chain derivation because the derivation process must decode the batches that have been encoded for the purpose of batch submission. The batcher submits batcher transactions to a data availability provider . These transactions contain one or multiple channel frames , which are chunks of data belonging to a channel . A channel is a sequence of sequencer batches (for any L2 blocks) compressed together. The reason to group multiple batches together is simply to obtain a better compression rate, hence reducing data availability costs. Channels might be too large to fit in a single batcher transaction , hence we need to split it into chunks known as channel frames . A single batcher transaction can also carry multiple frames (belonging to the same or to different channels). This design gives use the maximum flexibility in how we aggregate batches into channels, and split channels over batcher transactions. It notably allows us to maximize data utilization in a batcher transaction: for instance it allows us to pack the final (small) frame of one channel with one or more frames from the next channel. Also note that we use a streaming compression scheme, and we do not need to know how many batches a channel will end up containing when we start a channel, or even as we send the first frames in the channel. And by splitting channels across multiple data transactions, the L2 can have larger block data than the data-availability layer may support. All of this is illustrated in the following diagram. Explanations below. batch derivation chain diagram The first line represents L1 blocks with their numbers. The boxes under the L1 blocks represent batcher transactions included within the block. The squiggles under the L1 blocks represent deposits (more specifically, events emitted by the deposit contract ). Each colored chunk within the boxes represents a channel frame . So A and B are channels whereas A0, A1, B0, B1, B2 are frames. Notice that: multiple channels are interleaved frames do not need to be transmitted in order a single batcher transaction can carry frames from multiple channels In the next line, the rounded boxes represent individual sequencer batches that were extracted from the channels. The four blue/purple/pink were derived from channel A while the other were derived from channel B. These batches are here represented in the order they were decoded from batches (in this case B is decoded first). Note The caption here says \"Channel B was seen first and will be decoded into batches first\", but this is not a requirement. For instance, it would be equally acceptable for an implementation to peek into the channels and decode the one that contains the oldest batches first. The rest of the diagram is conceptually distinct from the first part and illustrates L2 chain derivation after the channels have been reordered. The first line shows batcher transactions. Note that in this case, there exists an ordering of the batches that makes all frames within the channels appear contiguously. This is not true in general. For instance, in the second transaction, the position of A1 and B0 could have been inverted for exactly the same result — no changes needed in the rest of the diagram. The second line shows the reconstructed channels in proper order. The third line shows the batches extracted from the channel. Because the channels are ordered and the batches within a channel are sequential, this means the batches are ordered too. The fourth line shows the L2 block derived from each batch. Note that we have a 1-1 batch to block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there are \"gaps\" in the batches posted on L1. The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while the second number (the \"sequence number\") denotes the position within the epoch. Finally, the sixth line shows user-deposited transactions derived from the deposit contract event mentioned earlier. Note the 101-0 L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if frame B2 indicates that it is the last frame within the channel and (2) no empty blocks must be inserted. The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4 blocks, because the last frame of channel A appears in block 102, but belong to epoch 99. As for the comment on \"security types\", it explains the classification of blocks as used on L1 and L2. Unsafe L2 blocks : Safe L2 blocks : Finalized L2 blocks: refer to block that have been derived from finalized L1 data. These security levels map to the headBlockHash, safeBlockHash and finalizedBlockHash values transmitted when interacting with the execution-engine API .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission Wire Format","id":"143","title":"Batch Submission Wire Format"},"144":{"body":"Batcher transactions are encoded as version_byte ++ rollup_payload (where ++ denotes concatenation). version_byte rollup_payload 0 frame ... (one or more frames, concatenated) 1 da_commitment (experimental, see alt-da ) Unknown versions make the batcher transaction invalid (it must be ignored by the rollup node). All frames in a batcher transaction must be parseable. If any one frame fails to parse, the all frames in the transaction are rejected. Batch transactions are authenticated by verifying that the to address of the transaction matches the batch inbox address, and the from address matches the batch-sender address in the system configuration at the time of the L1 block that the transaction data is read from.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batcher Transaction Format","id":"144","title":"Batcher Transaction Format"},"145":{"body":"A channel frame is encoded as: frame = channel_id ++ frame_number ++ frame_data_length ++ frame_data ++ is_last channel_id = bytes16\nframe_number = uint16\nframe_data_length = uint32\nframe_data = bytes\nis_last = bool Where uint32 and uint16 are all big-endian unsigned integers. Type names should be interpreted to and encoded according to the Solidity ABI . All data in a frame is fixed-size, except the frame_data. The fixed overhead is 16 + 2 + 4 + 1 = 23 bytes. Fixed-size frame metadata avoids a circular dependency with the target total data length, to simplify packing of frames with varying content length. where: channel_id is an opaque identifier for the channel. It should not be reused and is suggested to be random; however, outside of timeout rules, it is not checked for validity frame_number identifies the index of the frame within the channel frame_data_length is the length of frame_data in bytes. It is capped to 1,000,000 bytes. frame_data is a sequence of bytes belonging to the channel, logically after the bytes from the previous frames is_last is a single byte with a value of 1 if the frame is the last in the channel, 0 if there are frames in the channel. Any other value makes the frame invalid (it must be ignored by the rollup node).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Format","id":"145","title":"Frame Format"},"146":{"body":"A channel is encoded by applying a streaming compression algorithm to a list of batches: rlp_batches = []\nfor batch in batches: rlp_batches.append(batch) where: batches is the input, a sequence of batches byte-encoded as per the next section (\"Batch Encoding\") rlp_batches is the concatenation of the RLP-encoded batches channel_encoding = zlib_compress(rlp_batches) where zlib_compress is the ZLIB algorithm (as specified in RFC-1950 ) with no dictionary. The Fjord upgrade introduces an additional versioned channel encoding format to support alternate compression algorithms. When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL (defined in the Protocol Parameters table ), in order to avoid \"zip-bomb\" types of attack (where a small compressed input decompresses to a humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained only the first MAX_RLP_BYTES_PER_CHANNEL decompressed bytes. The limit is set on RLP decoding, so all batches that can be decoded in MAX_RLP_BYTES_PER_CHANNEL will be accepted even if the size of the channel is greater than MAX_RLP_BYTES_PER_CHANNEL. The exact requirement is that length(input) <= MAX_RLP_BYTES_PER_CHANNEL. While the above pseudocode implies that all batches are known in advance, it is possible to perform streaming compression and decompression of RLP-encoded batches. This means it is possible to start including channel frames in a batcher transaction before we know how many batches (and how many frames) the channel will contain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Format","id":"146","title":"Channel Format"},"147":{"body":"Recall that a batch contains a list of transactions to be included in a specific L2 block. A batch is encoded as batch_version ++ content, where content depends on the batch_version. Prior to the Delta upgrade, batches all have batch_version 0 and are encoded as described below. batch_version content 0 rlp_encode([parent_hash, epoch_number, epoch_hash, timestamp, transaction_list]) where: batch_version is a single byte, prefixed before the RLP contents, alike to transaction typing. rlp_encode is a function that encodes a batch according to the RLP format , and [x, y, z] denotes a list containing items x, y and z parent_hash is the block hash of the previous L2 block epoch_number and epoch_hash are the number and hash of the L1 block corresponding to the sequencing epoch of the L2 block timestamp is the timestamp of the L2 block transaction_list is an RLP-encoded list of EIP-2718 encoded transactions. The Delta upgrade introduced an additional batch type, span batches . Unknown versions make the batch invalid (it must be ignored by the rollup node), as do malformed contents. The epoch_number and the timestamp must also respect the constraints listed in the Batch Queue section, otherwise the batch is considered invalid and will be ignored.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Format","id":"147","title":"Batch Format"},"148":{"body":"The above primarily describes the general encodings used in L2 chain derivation, primarily how batches are encoded within batcher transactions . This section describes how the L2 chain is produced from the L1 batches using a pipeline architecture. A verifier may implement this differently, but must be semantically equivalent to not diverge from the L2 chain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Architecture","id":"148","title":"Architecture"},"149":{"body":"Our architecture decomposes the derivation process into a pipeline made up of the following stages: L1 Traversal L1 Retrieval Frame Queue Channel Bank Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue The data flows from the start (outer) of the pipeline towards the end (inner). From the innermost stage the data is pulled from the outermost stage. However, data is processed in reverse order. Meaning that if there is any data to be processed in the last stage, it will be processed first. Processing proceeds in \"steps\" that can be taken at each stage. We try to take as many steps as possible in the last (most inner) stage before taking any steps in its outer stage, etc. This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing the derivation pipeline. Each stage can maintain its own inner state as necessary. In particular, each stage maintains a L1 block reference (number + hash) to the latest L1 block such that all data originating from previous blocks has been fully processed, and the data from that block is being or has been processed. This allows the innermost stage to account for finalization of the L1 data-availability used to produce the L2 chain, to reflect in the L2 chain forkchoice when the L2 chain inputs become irreversible. Let's briefly describe each stage of the pipeline.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Pipeline","id":"149","title":"L2 Chain Derivation Pipeline"},"15":{"body":"Users are the general class of network participants who: Submit transactions through a Sequencer or by interacting with contracts on Ethereum. Query transaction data from interfaces operated by verifiers.","breadcrumbs":"Background » Users","id":"15","title":"Users"},"150":{"body":"In the L1 Traversal stage, we simply read the header of the next L1 block. In normal operations, these will be new L1 blocks as they get created, though we can also read old blocks while syncing, or in case of an L1 re-org . Upon traversal of the L1 block, the system configuration copy used by the L1 retrieval stage is updated, such that the batch-sender authentication is always accurate to the exact L1 block that is read by the stage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Traversal","id":"150","title":"L1 Traversal"},"151":{"body":"In the L1 Retrieval stage, we read the block we get from the outer stage (L1 traversal), and extract data from its batcher transactions . A batcher transaction is one with the following properties: The to field is equal to the configured batcher inbox address. The sender, as recovered from the transaction signature (v, r, and s), is the batcher address loaded from the system config matching the L1 block of the data. Each batcher transaction is versioned and contains a series of channel frames to be read by the Frame Queue, see Batch Submission Wire Format . Each batcher transaction in the block is processed in the order they appear in the block by passing its calldata on to the next phase.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Retrieval","id":"151","title":"L1 Retrieval"},"152":{"body":"The Frame Queue buffers one data-transaction at a time, decoded into channel frames , to be consumed by the next stage. See Batcher transaction format and Frame format specifications.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Queue","id":"152","title":"Frame Queue"},"153":{"body":"The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1 retrieval stage. A step in the channel bank stage tries to read data from channels that are \"ready\". Channels are currently fully buffered until read or dropped, streaming channels may be supported in a future version of the ChannelBank. To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels. Channels are recorded in FIFO order in a structure called the channel queue . A channel is added to the channel queue the first time a frame belonging to the channel is seen. Pruning After successfully inserting a new frame, the ChannelBank is pruned: channels are dropped in FIFO order, until total_size <= MAX_CHANNEL_BANK_SIZE, where: total_size is the sum of the sizes of each channel, which is the sum of all buffered frame data of the channel, with an additional frame-overhead of 200 bytes per frame. MAX_CHANNEL_BANK_SIZE is a protocol constant defined in the Protocol Parameters table . Timeouts The L1 origin that the channel was opened in is tracked with the channel as channel.open_l1_block, and determines the maximum span of L1 blocks that the channel data is retained for, before being pruned. A channel is timed out if: current_l1_block.number > channel.open_l1_block.number + CHANNEL_TIMEOUT, where: current_l1_block is the L1 origin that the stage is currently traversing. CHANNEL_TIMEOUT is a rollup-configurable, expressed in number of L1 blocks. New frames for timed-out channels are dropped instead of buffered. Reading Upon reading, while the first opened channel is timed-out, remove it from the channel-bank. Prior to the Canyon network upgrade, once the first opened channel, if any, is not timed-out and is ready, then it is read and removed from the channel-bank. After the Canyon network upgrade, the entire channel bank is scanned in FIFO order (by open time) & the first ready (i.e. not timed-out) channel will be returned. The canyon behavior will activate when frames from a L1 block whose timestamp is greater than or equal to the canyon time first enter the channel queue. A channel is ready if: The channel is closed The channel has a contiguous sequence of frames until the closing frame If no channel is ready, the next frame is read and ingested into the channel bank. Loading frames When a channel ID referenced by a frame is not already present in the Channel Bank, a new channel is opened, tagged with the current L1 block, and appended to the channel-queue. Frame insertion conditions: New frames matching timed-out channels that have not yet been pruned from the channel-bank are dropped. Duplicate frames (by frame number) for frames that have not been pruned from the channel-bank are dropped. Duplicate closes (new frame is_last == 1, but the channel has already seen a closing frame and has not yet been pruned from the channel-bank) are dropped. If a frame is closing (is_last == 1) any existing higher-numbered frames are removed from the channel. Note that while this allows channel IDs to be reused once they have been pruned from the channel-bank, it is recommended that batcher implementations use unique channel IDs.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Bank","id":"153","title":"Channel Bank"},"154":{"body":"In this stage, we decompress the channel we pull from the last stage, and then parse batches from the decompressed byte stream. See Channel Format and Batch Format for decompression and decoding specification.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Reader (Batch Decoding)","id":"154","title":"Channel Reader (Batch Decoding)"},"155":{"body":"During the Batch Buffering stage, we reorder batches by their timestamps. If batches are missing for some time slots and a valid batch with a higher timestamp exists, this stage also generates empty batches to fill the gaps. Batches are pushed to the next stage whenever there is one sequential batch directly following the timestamp of the current safe L2 head (the last block that can be derived from the canonical L1 chain). The parent hash of the batch must also match the hash of the current safe L2 head. Note that the presence of any gaps in the batches derived from L1 means that this stage will need to buffer for a whole sequencing window before it can generate empty batches (because the missing batch(es) could have data in the last L1 block of the window in the worst case). A batch can have 4 different forms of validity: drop: the batch is invalid, and will always be in the future, unless we reorg. It can be removed from the buffer. accept: the batch is valid and should be processed. undecided: we are lacking L1 information until we can proceed batch filtering. future: the batch may be valid, but cannot be processed yet and should be checked again later. The batches are processed in order of the inclusion on L1: if multiple batches can be accept-ed the first is applied. An implementation can defer future batches a later derivation step to reduce validation work. The batches validity is derived as follows: Definitions: batch as defined in the Batch format section . epoch = safe_l2_head.l1_origin a L1 origin coupled to the batch, with properties: number (L1 block number), hash (L1 block hash), and timestamp (L1 block timestamp). inclusion_block_number is the L1 block number when batch was first fully derived, i.e. decoded and output by the previous stage. next_timestamp = safe_l2_head.timestamp + block_time is the expected L2 timestamp the next batch should have, see block time information . next_epoch may not be known yet, but would be the L1 block after epoch if available. batch_origin is either epoch or next_epoch, depending on validation. Note that processing of a batch can be deferred until batch.timestamp <= next_timestamp, since future batches will have to be retained anyway. Rules, in validation order: batch.timestamp > next_timestamp -> future: i.e. the batch must be ready to process. batch.timestamp < next_timestamp -> drop: i.e. the batch must not be too old. batch.parent_hash != safe_l2_head.hash -> drop: i.e. the parent hash must be equal to the L2 safe head block hash. batch.epoch_num + sequence_window_size < inclusion_block_number -> drop: i.e. the batch must be included timely. batch.epoch_num < epoch.number -> drop: i.e. the batch origin is not older than that of the L2 safe head. batch.epoch_num == epoch.number: define batch_origin as epoch. batch.epoch_num == epoch.number+1: If next_epoch is not known -> undecided: i.e. a batch that changes the L1 origin cannot be processed until we have the L1 origin data. If known, then define batch_origin as next_epoch batch.epoch_num > epoch.number+1 -> drop: i.e. the L1 origin cannot change by more than one L1 block per L2 block. batch.epoch_hash != batch_origin.hash -> drop: i.e. a batch must reference a canonical L1 origin, to prevent batches from being replayed onto unexpected L1 chains. batch.timestamp < batch_origin.time -> drop: enforce the min L2 timestamp rule. batch.timestamp > batch_origin.time + max_sequencer_drift: enforce the L2 timestamp drift rule, but with exceptions to preserve above min L2 timestamp invariant: len(batch.transactions) == 0: epoch.number == batch.epoch_num: this implies the batch does not already advance the L1 origin, and must thus be checked against next_epoch. If next_epoch is not known -> undecided: without the next L1 origin we cannot yet determine if time invariant could have been kept. If batch.timestamp >= next_epoch.time -> drop: the batch could have adopted the next L1 origin without breaking the L2 time >= L1 time invariant. len(batch.transactions) > 0: -> drop: when exceeding the sequencer time drift, never allow the sequencer to include transactions. batch.transactions: drop if the batch.transactions list contains a transaction that is invalid or derived by other means exclusively: any transaction that is empty (zero length byte string) any deposited transactions (identified by the transaction type prefix byte) If no batch can be accept-ed, and the stage has completed buffering of all batches that can fully be read from the L1 block at height epoch.number + sequence_window_size, and the next_epoch is available, then an empty batch can be derived with the following properties: parent_hash = safe_l2_head.hash timestamp = next_timestamp transactions is empty, i.e. no sequencer transactions. Deposited transactions may be added in the next stage. If next_timestamp < next_epoch.time: the current L1 origin is repeated, to preserve the L2 time invariant. epoch_num = epoch.number epoch_hash = epoch.hash If the batch is the first batch of the epoch, that epoch is used instead of advancing the epoch to ensure that there is at least one L2 block per epoch. epoch_num = epoch.number epoch_hash = epoch.hash Otherwise, epoch_num = next_epoch.number epoch_hash = next_epoch.hash","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Queue","id":"155","title":"Batch Queue"},"156":{"body":"In the Payload Attributes Derivation stage, we convert the batches we get from the previous stage into instances of the PayloadAttributes structure. Such a structure encodes the transactions that need to figure into a block, as well as other block inputs (timestamp, fee recipient, etc). Payload attributes derivation is detailed in the section Deriving Payload Attributes section below. This stage maintains its own copy of the system configuration , independent of the L1 retrieval stage. The system configuration is updated with L1 log events whenever the L1 epoch referenced by the batch input changes.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Payload Attributes Derivation","id":"156","title":"Payload Attributes Derivation"},"157":{"body":"In the Engine Queue stage, the previously derived PayloadAttributes structures are buffered and sent to the execution engine to be executed and converted into a proper L2 block. The stage maintains references to three L2 blocks: The finalized L2 head : everything up to and including this block can be fully derived from the finalized (i.e. canonical and forever irreversible) part of the L1 chain. The safe L2 head : everything up to and including this block can be fully derived from the currently canonical L1 chain. The unsafe L2 head : blocks between the safe and unsafe heads are unsafe blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer mode) or from unsafe sync to the sequencer (in validator mode). This is also known as the \"latest\" head. Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references from which L1 blocks each was derived. This history does not have to be complete, but enables later L1 finality signals to be translated into L2 finality. Engine API usage To interact with the engine, the execution engine API is used, with the following JSON-RPC methods: Bedrock, Canyon, Delta: API Usage engine_forkchoiceUpdatedV2 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV2 — retrieves a previously requested execution payload build. engine_newPayloadV2 — executes an execution payload to create a block. Ecotone: API Usage engine_forkchoiceUpdatedV3 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV3 — retrieves a previously requested execution payload build. engine_newPayload engine_newPayloadV2 — executes a Bedrock/Canyon/Delta execution payload to create a block. engine_newPayloadV3 — executes an Ecotone execution payload to create a block. The current version of op-node uses the v3 Engine API RPC methods as well as engine_newPayloadV2, due to engine_newPayloadV3 only supporting Ecotone execution payloads. Both engine_forkchoiceUpdatedV3 and engine_getPayloadV3 are backwards compatible with Bedrock, Canyon & Delta payloads. Prior versions of op-node used v2 and v1 methods. The execution payload is an object of type ExecutionPayloadV3 . The ExecutionPayload has the following requirements: Bedrock The withdrawals field MUST be nil The blob gas used field MUST be nil The blob gas limit field MUST be nil Canyon, Delta The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be nil The blob gas limit field MUST be nil Ecotone The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be 0 The blob gas limit field MUST be 0 Forkchoice synchronization If there are any forkchoice updates to be applied, before additional inputs are derived or processed, then these are applied to the engine first. This synchronization may happen when: A L1 finality signal finalizes one or more L2 blocks: updating the \"finalized\" L2 block. A successful consolidation of unsafe L2 blocks: updating the \"safe\" L2 block. The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state. The new forkchoice state is applied by calling fork choice updated on the engine API. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. L1-consolidation: payload attributes matching If the unsafe head is ahead of the safe head, then consolidation is attempted, verifying that existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data. During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If the payload attributes match this oldest unsafe L2 block, then that block can be considered \"safe\" and becomes the new safe head. The following fields of the derived L2 payload attributes are checked for equality with the L2 block: Bedrock, Canyon, Delta, Ecotone Blocks parent_hash timestamp randao fee_recipient transactions_list (first length, then equality of each of the encoded transactions, including deposits) gas_limit Canyon, Delta, Ecotone Blocks withdrawals (first presence, then length, then equality of each of the encoded withdrawals) Ecotone Blocks parent_beacon_block_root If consolidation succeeds, the forkchoice change will synchronize as described in the section above. If consolidation fails, the L2 payload attributes will be processed immediately as described in the section below. The payload attributes are chosen in favor of the previous unsafe L2 block, creating an L2 chain reorg on top of the current safe block. Immediately processing the new alternative attributes enables execution engines like go-ethereum to enact the change, as linear rewinds of the tip of the chain may not be supported. L1-sync: payload attributes processing If the safe and unsafe L2 heads are identical (whether because of failed consolidation or not), we send the L2 payload attributes to the execution engine to be constructed into a proper L2 block. This L2 block will then become both the new L2 safe and unsafe head. If a payload attributes created from a batch cannot be inserted into the chain because of a validation error (i.e. there was an invalid transaction or state transition in the block) the batch should be dropped & the safe head should not be advanced. The engine queue will attempt to use the next batch for that timestamp from the batch queue. If no valid batch is found, the rollup node will create a deposit only batch which should always pass validation because deposits are always valid. Interaction with the execution engine via the execution engine API is detailed in the Communication with the Execution Engine section. The payload attributes are then processed with a sequence of: Engine: Fork choice updated with current forkchoice state of the stage, and the attributes to start block building. Non-deterministic sources, like the tx-pool, must be disabled to reconstruct the expected block. Engine: Get Payload to retrieve the payload, by the payload-ID in the result of the previous step. Engine: New Payload to import the new payload into the execution engine. Engine: Fork Choice Updated to make the new payload canonical, now with a change of both safe and unsafe fields to refer to the payload, and no payload attributes. Engine API Error handling: On RPC-type errors the payload attributes processing should be re-attempted in a future step. On payload processing errors the attributes must be dropped, and the forkchoice state must be left unchanged. Eventually the derivation pipeline will produce alternative payload attributes, with or without batches. If the payload attributes only contained deposits, then it is a critical derivation error if these are invalid. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. Processing unsafe payload attributes If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as an \"unsafe\" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the user to see the head of the L2 chain faster than the L1 may confirm the L2 batches. To process unsafe payloads, the payload must: Have a block number higher than the current safe L2 head. The safe L2 head may only be reorged out due to L1 reorgs. Have a parent blockhash that matches the current unsafe L2 head. This prevents the execution engine individually syncing a larger gap in the unsafe L2 chain. This prevents unsafe L2 blocks from reorging other previously validated L2 blocks. This check may change in the future versions to adopt e.g. the L1 snap-sync protocol. The payload is then processed with a sequence of: Bedrock/Canyon/Delta Payloads engine_newPayloadV2: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV2: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Ecotone Payloads engine_newPayloadV3: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV3: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Engine API Error handling: On RPC-type errors the payload processing should be re-attempted in a future step. On payload processing errors the payload must be dropped, and not be marked as canonical. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Engine Queue","id":"157","title":"Engine Queue"},"158":{"body":"It is possible to reset the pipeline, for instance if we detect an L1 reorg (reorganization) . This enables the rollup node to handle L1 chain reorg events. Resetting will recover the pipeline into a state that produces the same outputs as a full L2 derivation process, but starting from an existing L2 chain that is traversed back just enough to reconcile with the current L1 chain. Note that this algorithm covers several important use-cases: Initialize the pipeline without starting from 0, e.g. when the rollup node restarts with an existing engine instance. Recover the pipeline if it becomes inconsistent with the execution engine chain, e.g. when the engine syncs/changes. Recover the pipeline when the L1 chain reorganizes, e.g. a late L1 block is orphaned, or a larger attestation failure. Initialize the pipeline to derive a disputed L2 block with prior L1 and L2 history inside a fault-proof program. Handling these cases also means a node can be configured to eagerly sync L1 data with 0 confirmations, as it can undo the changes if the L1 later does recognize the data as canonical, enabling safe low-latency usage. The Engine Queue is first reset, to determine the L1 and L2 starting points to continue derivation from. After this, the other stages are reset independent of each other. Finding the sync starting point To find the starting point, there are several steps, relative to the head of the chain traversing back: Find the current L2 forkchoice state If no finalized block can be found, start at the Bedrock genesis block. If no safe block can be found, fallback to the finalized block. The unsafe block should always be available and consistent with the above (it may not be in rare engine-corruption recovery cases, this is being reviewed). Find the first L2 block with plausible L1 reference to be the new unsafe starting point, starting from previous unsafe, back to finalized and no further. Plausible iff: the L1 origin of the L2 block is known and canonical, or unknown and has a block-number ahead of L1. Find the first L2 block with an L1 reference older than the sequencing window, to be the new safe starting point, starting at the above plausible unsafe head, back to finalized and no further. If at any point the L1 origin is known but not canonical, the unsafe head is revised to parent of the current. The highest L2 block with known canonical L1 origin is remembered as highest. If at any point the L1 origin in the block is corrupt w.r.t. derivation rules, then error. Corruption includes: Inconsistent L1 origin block number or parent-hash with parent L1 origin Inconsistent L1 sequence number (always changes to 0 for a L1 origin change, or increments by 1 if not) If the L1 origin of the L2 block n is older than the L1 origin of highest by more than a sequence window, and n.sequence_number == 0, then the parent L2 block of n will be the safe starting point. The finalized L2 block persists as the finalized starting point. Find the first L2 block with an L1 reference older than the channel-timeout The L1 origin referenced by this block which we call l2base will be the base for the L2 pipeline derivation: By starting here, the stages can buffer any necessary data, while dropping incomplete derivation outputs until L1 traversal has caught up with the actual L2 safe head. While traversing back the L2 chain, an implementation may sanity-check that the starting point is never set too far back compared to the existing forkchoice state, to avoid an intensive reorg because of misconfiguration. Implementers note: step 1-4 are known as FindL2Heads. Step 5 is currently part of the Engine Queue reset. This may change to isolate the starting-point search from the bare reset logic. Resetting derivation stages L1 Traversal: start at L1 base as first block to be pulled by next stage. L1 Retrieval: empty previous data, and fetch the base L1 data, or defer the fetching work to a later pipeline step. Frame Queue: empty the queue. Channel Bank: empty the channel bank. Channel Reader: reset any batch decoding state. Batch Queue: empty the batch queue, use base as initial L1 point of reference. Payload Attributes Derivation: empty any batch/attributes state. Engine Queue: Initialize L2 forkchoice state with syncing start point state. (finalized/safe/unsafe) Initialize the L1 point of reference of the stage to base. Require a forkchoice update as first task Reset any finality data Where necessary, stages starting at base can initialize their system-config from data encoded in the l2base block. About reorgs Post-Merge Note that post- merge , the depth of reorgs will be bounded by the L1 finality delay (2 L1 beacon epochs, or approximately 13 minutes, unless more than 1/3 of the network consistently disagrees). New L1 blocks may be finalized every L1 beacon epoch (approximately 6.4 minutes), and depending on these finality-signals and batch-inclusion, the derived L2 chain will become irreversible as well. Note that this form of finalization only affects inputs, and nodes can then subjectively say the chain is irreversible, by reproducing the chain from these irreversible inputs and the set protocol rules and parameters. This is however completely unrelated to the outputs posted on L1, which require a form of proof like a fault-proof or zk-proof to finalize. Optimistic-rollup outputs like withdrawals on L1 are only labeled \"finalized\" after passing a week without dispute (fault proof challenge window), a name-collision with the proof-of-stake finalization.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Resetting the Pipeline","id":"158","title":"Resetting the Pipeline"},"159":{"body":"For every L2 block derived from L1 data, we need to build payload attributes , represented by an expanded version of the PayloadAttributesV2 object, which includes additional transactions and noTxPool fields. This process happens during the payloads-attributes queue ran by a verifier node, as well as during block-production ran by a sequencer node (the sequencer may enable the tx-pool usage if the transactions are batch-submitted).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving Payload Attributes","id":"159","title":"Deriving Payload Attributes"},"16":{"body":"Sequencers fill the role of the block producer on an OP Stack chain. Chains may have a single Sequencer or may choose to utilize some consensus protocol that coordinates multiple Sequencers. The OP Stack currently officially only supports a single active Sequencer at any given time. In general, specifications may use the term \"the Sequencer\" as a stand-in for either a single Sequencer or a consensus protocol of multiple Sequencers. The Sequencer: Accepts transactions directly from Users. Observes \"deposit\" transactions generated on Ethereum. Consolidates both transaction streams into ordered L2 blocks. Submits information to L1 that is sufficient to fully reproduce those L2 blocks. Provides real-time access to pending L2 blocks that have not yet been confirmed on L1. The Sequencer serves an important role for the operation of an L2 chain but is not a trusted actor. The Sequencer is generally responsible for improving the user experience by ordering transactions much more quickly and cheaply than would currently be possible if users were to submit all transactions directly to L1.","breadcrumbs":"Background » Sequencers","id":"16","title":"Sequencers"},"160":{"body":"For each L2 block to be created by the sequencer, we start from a sequencer batch matching the target L2 block number. This could potentially be an empty auto-generated batch, if the L1 chain did not include a batch for the target L2 block number. Remember that the batch includes a sequencing epoch number, an L2 timestamp, and a transaction list. This block is part of a sequencing epoch , whose number matches that of an L1 block (its L1 origin ). This L1 block is used to derive L1 attributes and (for the first L2 block in the epoch) user deposits. Therefore, a PayloadAttributesV2 object must include the following transactions: one or more deposited transactions , of two kinds: a single L1 attributes deposited transaction , derived from the L1 origin. for the first L2 block in the epoch, zero or more user-deposited transactions , derived from the receipts of the L1 origin. zero or more network upgrade automation transactions : special transactions to perform network upgrades. zero or more sequenced transactions : regular transactions signed by L2 users, included in the sequencer batch. Transactions must appear in this order in the payload attributes. The L1 attributes are read from the L1 block header, while deposits are read from the L1 block's receipts . Refer to the deposit contract specification for details on how deposits are encoded as log entries.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving the Transaction List","id":"160","title":"Deriving the Transaction List"},"161":{"body":"Some network upgrades require automated contract changes or deployments at specific blocks. To automate these, without adding persistent changes to the execution-layer, special transactions may be inserted as part of the derivation process. Ecotone The Ecotone hardfork activation block contains the following transactions, in this order: L1 Attributes Transaction, using the pre-Ecotone setL1BlockValues User deposits from L1 Network Upgrade Transactions L1Block deployment GasPriceOracle deployment Update L1Block Proxy ERC-1967 Implementation Slot Update GasPriceOracle Proxy ERC-1967 Implementation Slot GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) To not modify or interrupt the system behavior around gas computation, this block will not include any sequenced transactions by setting noTxPool: true. L1Block Deployment The L1Block contract is upgraded to process the new Ecotone L1-data-fee parameters and L1 blob base-fee. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000000 to: null mint: 0 value: 0 gasLimit: 375,000 data: 0x60806040523480156100105... ( full bytecode ) sourceHash: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Deployment\" This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000000\nComputed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Deployment\"))\n# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json This transaction MUST deploy a contract with the following code hash 0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd. GasPriceOracle Deployment The GasPriceOracle contract is upgraded to support the new Ecotone L1-data-fee parameters. Post fork this contract will use the blob base fee to compute the gas price for L1-data-fee transactions. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000001 to: null, mint: 0 value: 0 gasLimit: 1,000,000 data: 0x60806040523480156100... ( full bytecode ) sourceHash: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Deployment\" This results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000001\nComputed Address: 0xb528D11cC114E026F138fE568744c6D45ce6Da7A Verify sourceHash: ❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Deployment\"))\n# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json This transaction MUST deploy a contract with the following code hash 0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5. L1Block Proxy Update This transaction updates the L1Block Proxy ERC-1967 implementation slot to point to the new L1Block deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x4200000000000000000000000000000000000015 (L1Block Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff sourceHash: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)\n0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Proxy Update\"))\n# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc GasPriceOracle Proxy Update This transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a sourceHash: 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: Gas Price Oracle Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)\n0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Proxy Update\"))\n# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a GasPriceOracle Enable Ecotone This transaction informs the GasPriceOracle to start using the Ecotone gas calculation formula. A deposit transaction is derived with the following attributes: from: 0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 (Depositer Account) to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 80,000 data: 0x22b90ab3 sourceHash: 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Set Ecotone\" Verify data: cast sig \"setEcotone()\"\n0x22b90ab3 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Set Ecotone\"))\n# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93 Beacon block roots contract deployment (EIP-4788) EIP-4788 introduces a \"Beacon block roots\" contract, that processes and exposes the beacon-block-root values. at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02. For deployment, EIP-4788 defines a pre- EIP-155 legacy transaction, sent from a key that is derived such that the transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code. However, this type of transaction requires manual deployment and gas-payments. And since the processing is an integral part of the chain processing, and has to be repeated for every OP-Stack chain, the deployment is approached differently here. Some chains may already have a user-submitted instance of the EIP-4788 transaction. This is cryptographically guaranteed to be correct, but may result in the upgrade transaction deploying a second contract, with the next nonce. The result of this deployment can be ignored. A Deposit transaction is derived with the following attributes: from: 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875, as specified in the EIP. to: null mint: 0 value: 0 gasLimit: 0x3d090, as specified in the EIP. isCreation: true data: 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500 isSystemTx: false, as per the Regolith upgrade, even the system-generated transactions spend gas. sourceHash: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c, computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: beacon block roots contract deployment\" The contract address upon deployment is computed as rlp([sender, nonce]), which will equal: BEACON_ROOTS_ADDRESS if deployed a different address (0xE3aE1Ae551eeEda337c0BfF6C4c7cbA98dce353B) if nonce = 1: when a user already submitted the EIP transaction before the upgrade. Verify BEACON_ROOTS_ADDRESS: cast compute-address --nonce=0 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875\n# Computed Address: 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: beacon block roots contract deployment\"))\n# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Network upgrade automation transactions","id":"161","title":"Network upgrade automation transactions"},"162":{"body":"After deriving the transactions list, the rollup node constructs a PayloadAttributesV2 as follows: timestamp is set to the batch's timestamp. random is set to the prev_randao L1 block attribute. suggestedFeeRecipient is set to the Sequencer Fee Vault address. See Fee Vaults specification. transactions is the array of the derived transactions: deposited transactions and sequenced transactions, all encoded with EIP-2718 . noTxPool is set to true, to use the exact above transactions list when constructing the block. gasLimit is set to the current gasLimit value in the system configuration of this payload. withdrawals is set to nil prior to Canyon and an empty array after Canyon","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Building Individual Payload Attributes","id":"162","title":"Building Individual Payload Attributes"},"163":{"body":"Table of Contents Overview","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Batch Submitter","id":"163","title":"Batch Submitter"},"164":{"body":"The batch submitter, also referred to as the batcher, is the entity submitting the L2 sequencer data to L1, to make it available for verifiers. The format of the data transactions is defined in the derivation spec : the data is constructed from L2 blocks in the reverse order as it is derived from data into L2 blocks. The timing, operation and transaction signing is implementation-specific: any data can be submitted at any time, but only the data that matches the derivation spec rules will be valid from the verifier perspective. The most minimal batcher implementation can be defined as a loop of the following operations: See if the unsafe L2 block number is past the safe block number: unsafe data needs to be submitted. Iterate over all unsafe L2 blocks, skip any that were previously submitted. Open a channel, buffer all the L2 block data to be submitted, while applying the encoding and compression as defined in the derivation spec . Pull frames from the channel to fill data transactions with, until the channel is empty. Submit the data transactions to L1 The L2 view of safe/unsafe does not instantly update after data is submitted, nor when it gets confirmed on L1, so special care may have to be taken to not duplicate data submissions.","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Overview","id":"164","title":"Overview"},"165":{"body":"Table of Contents Overview Pre-image Oracle Pre-image key types Type 0: Zero key Type 1: Local key Type 2: Global keccak256 key Type 3: Global generic key Type 4: Global SHA2-256 key Type 5: Global EIP-4844 Point-evaluation key Type 6: Global Precompile key Type 7-128: reserved range Type 129-255: application usage Bootstrapping Hinting Pre-image communication Fault Proof Program Prologue Main content Epilogue Pre-image hinting routes l1-block-header l1-transactions l1-receipts l1-precompile l2-block-header l2-transactions l2-code l2-state-node l2-output Precompile Accelerators Fault Proof VM Fault Proof Interactive Dispute Game","breadcrumbs":"OP Stack Protocol » Fault Proof » Fault Proof","id":"165","title":"Fault Proof"},"166":{"body":"A fault proof, also known as fraud proof or interactive game, consists of 3 components: Program : given a commitment to all rollup inputs (L1 data) and the dispute, verify the dispute statelessly. VM : given a stateless program and its inputs, trace any instruction step, and prove it on L1. Interactive Dispute Game : bisect a dispute down to a single instruction, and resolve the base-case using the VM. Each of these 3 components may have different implementations, which can be combined into different proof stacks, and contribute to proof diversity when resolving a dispute. \"Stateless execution\" of the program, and its individual instructions, refers to reproducing the exact same computation by authenticating the inputs with a Pre-image Oracle . Diagram of Program and VM architecture","breadcrumbs":"OP Stack Protocol » Fault Proof » Overview","id":"166","title":"Overview"},"167":{"body":"The pre-image oracle is the only form of communication between the Program (in the Client role) and the VM (in the Server role). The program uses the pre-image oracle to query any input data that is understood to be available to the user: The initial inputs to bootstrap the program. See Bootstrapping . External data not already part of the program code. See Pre-image hinting routes . The communication happens over a simple request-response wire protocol, see Pre-image communication .","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image Oracle","id":"167","title":"Pre-image Oracle"},"168":{"body":"Pre-images are identified by a bytes32 type-prefixed key: The first byte identifies the type of request. The remaining 31 bytes identify the pre-image key. Type 0: Zero key The zero prefix is illegal. This ensures all pre-image keys are non-zero, enabling storage lookup optimizations and avoiding easy mistakes with invalid zeroed keys in the EVM. Type 1: Local key Information specific to the dispute: the remainder of the key may be an index, a string, a hash, etc. Only the contract(s) managing this dispute instance may serve the value for this key: it is localized and context-dependent. This type of key is used for program bootstrapping, to identify the initial input arguments by index or name. Type 2: Global keccak256 key This type of key uses a global pre-image store contract, and is fully context-independent and permissionless. I.e. every key must have a single unique value, regardless of chain history or time. Using a global store reduces duplicate pre-image registration work, and avoids unnecessary contract redeployments per dispute. This global store contract should be non-upgradeable. Since keccak256 is a safe 32-byte hash input, the first byte is overwritten with a 2 to derive the key, while keeping the rest of the key \"readable\" (matching the original hash). Type 3: Global generic key Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments. This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:], where: x is a bytes32, which can be a hash of an arbitrary-length type of cryptographically secure commitment. sender is a bytes32 identifying the pre-image inserter address (left-padded to 32 bytes) This global store contract should be non-upgradeable. The global contract is permissionless: users can standardize around external contracts that verify pre-images (i.e. a specific sender will always be trusted for a specific kind of pre-image). The external contract verifies the pre-image before inserting it into the global store for usage by all fault proof VMs without requiring the VM or global store contract to be changed. Users may standardize around upgradeable external pre-image contracts, in case the implementation of the verification of the pre-image is expected to change. The store update function is update(x bytes32, offset uint64, span uint8, value bytes32): x is the bytes32 x that the pre-image key is computed with. Only part of the pre-image, starting at offset, and up to (incl.) 32 bytes span can be inserted at a time. Pre-images may have an undefined length (e.g. a stream), we only need to know how many bytes of value are usable. The key and offset will be hashed together to uniquely store the value and span, for later pre-image serving. This enables fault proof programs to adopt any new pre-image schemes without VM update or contract redeployment. It is up to the user to index the special pre-image values by this key scheme, as there is no way to revert it to the original commitment without knowing said commitment or value. Type 4: Global SHA2-256 key A SHA-256 pre-image. Key: the SHA-256 hash, with the first byte overwritten with the type byte: 4 ++ sha256(data)[1:]. Type 5: Global EIP-4844 Point-evaluation key An EIP-4844 point-evaluation. In an EIP-4844 blob, 4096 field elements represent the blob data. It verifies p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof. The value y is the pre-image. The value z is part of the key; the index of the point within the blob. The commitment is part of the key. Each element is proven with a point-evaluation. Key: 5 ++ keccak256(commitment ++ z)[1:], where: 5 is the type byte ++ is concatenation commitment is a bytes48, representing the KZG commitment. z is a big-endian uint256 Type 6: Global Precompile key A precompile result. It maps directly to precompiles on Ethereum. This preimage key can be used to avoid running expensive precompile operations in the program. Key: 6 ++ keccak256(precompile ++ input)[1:], where: 6 is the type byte ++ is concatenation precompile is the 20-byte address of the precompile contract input is the input to the precompile contract The result is identical to that of a call to the precompile contract, prefixed with a revert indicator: reverted ++ precompile_result. reverted is a 1-byte indicator with a 0 value if the precompile reverts for the given input, otherwise it's 1. Type 7-128: reserved range Range start and end both inclusive. This range of key types is reserved for future usage by the core protocol. E.g. version changes, contract migrations, chain-data, additional core features, etc. 128 specifically (1000 0000 in binary) is reserved for key-type length-extension (reducing the content part to 30 or less key bytes), if the need arises. Type 129-255: application usage This range of key types may be used by forks or customized versions of the fault proof protocol.","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image key types","id":"168","title":"Pre-image key types"},"169":{"body":"Initial inputs are deterministic, but not necessarily singular or global: there may be multiple different disputes at the same time, each with its own disputed claims and L1 context. To bootstrap, the program requests the initial inputs from the VM, using pre-image key type 1. The VM is aware of the external context, and maps requested pre-image keys based on their type, i.e. a local lookup for type 1, or global one for 2, and optionally support other key-types.","breadcrumbs":"OP Stack Protocol » Fault Proof » Bootstrapping","id":"169","title":"Bootstrapping"},"17":{"body":"Verifiers download and execute the L2 state transition function independently of the Sequencer. Verifiers help to maintain the integrity of the network and serve blockchain data to Users. Verifiers generally: Download rollup data from L1 and the Sequencer. Use rollup data to execute the L2 state transition function. Serve rollup data and computed L2 state information to Users. Verifiers can also act as Proposers and/or Challengers who: Submit assertions about the state of the L2 to a smart contract on L1. Validate assertions made by other participants. Dispute invalid assertions made by other participants.","breadcrumbs":"Background » Verifiers","id":"17","title":"Verifiers"},"170":{"body":"There is one more form of optional communication between client and server: pre-image hinting. Hinting is optional, and is a no-op in a L1 VM implementation. The hint itself comes at very low cost onchain: the hint can be a single write sys-call, which is instant as the memory to write as hint does not actually need to be loaded as part of the onchain proof. Hinting allows the program, when generating a proof offchain, to instruct the VM what data it is interested in. The VM can choose to execute the requested hint at any time: either locally (for standard requests), or in a modular form by redirecting the hint to tooling that may come with the VM program. Hints do not have to be executed directly: they may first just be logged to show the intents of the program, and the latest hint may be buffered for lazy execution, or dropped entirely when in read-only mode (like onchain). When the pre-image oracle serves a request, and the request cannot be served from an existing collection of pre-images (e.g. a local pre-image cache) then the VM can execute the hint to retrieve the missing pre-image(s). It is the responsibility of the program to provide sufficient hinting for every pre-image request. Some hints may have to be repeated: the VM only has to execute the last hint when handling a missing pre-image. Note that hints may produce multiple pre-images: e.g. a hint for an ethereum block with transaction list may prepare pre-images for the header, each of the transactions, and the intermediate merkle-nodes that form the transactions-list Merkle Patricia Trie. Hinting is implemented with a request-acknowledgement wire-protocol over a blocking two-way stream: := := := big-endian uint32 # length of \n := byte sequence\n := 1-byte zero value The ack informs the client that the hint has been processed. Servers may respond to hints and pre-image (see below) requests asynchronously as they are on separate streams. To avoid requesting pre-images that are not yet fetched, clients should request the pre-image only after it has observed the hint acknowledgement.","breadcrumbs":"OP Stack Protocol » Fault Proof » Hinting","id":"170","title":"Hinting"},"171":{"body":"Pre-images are communicated with a minimal wire-protocol over a blocking two-way stream. This protocol can be implemented with blocking read/write syscalls. :=
By chosing to put the eip1559Params in the PayloadAttributes rather than in the L1 block info transaction, the EIP-1559 parameters for the chain are not available within history. This would place a burden on performing historical execution, as L1 would have to be consulted for fetching the values from the SystemConfig contract. diff --git a/protocol/holocene/overview.html b/protocol/holocene/overview.html index 0ce159035..1714698a1 100644 --- a/protocol/holocene/overview.html +++ b/protocol/holocene/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -199,10 +199,9 @@ Smart Contracts -This document is not finalized and should be considered experimental. Execution Layer -L2ToL1MessagePasser Storage Root in Header +Dynamic EIP-1559 Parameters Consensus Layer @@ -210,8 +209,7 @@ Consensus Lay Smart Contracts -Predeploys -Configurability +System Config diff --git a/protocol/holocene/predeploys.html b/protocol/holocene/predeploys.html index 3c4f9c31d..3c6067ec3 100644 --- a/protocol/holocene/predeploys.html +++ b/protocol/holocene/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -189,209 +189,7 @@ OP Stack Specification -Overview - - -Table of Contents - -Constants -Predeploys - -L1Block - -Storage -Interface - -setHolocene -setConfig -baseFeeVaultConfig -sequencerFeeVaultConfig -l1FeeVaultConfig -l1CrossDomainMessenger -l1StandardBridge -l1ERC721Bridge -remoteChainId - - - - -FeeVault - -Interface - -config - - - - -L2CrossDomainMessenger - -Interface - - -L2ERC721Bridge - -Interface - - -L2StandardBridge - -Interface - - -OptimismMintableERC721Factory - - -Security Considerations - -GovernanceToken - - - - -This upgrade enables a deterministic L2 genesis state by moving all network -specific configuration out of the initial L2 genesis state. All network specific -configuration is sourced from deposit transactions during the initialization -of the SystemConfig. -Constants -NameValueDefinition -ConfigTypeuint8An enum representing the type of config being set -WithdrawalNetworkuint8(0) or uint8(1)0 means withdraw to L1, 1 means withdraw to L2 -RECIPIENTaddressThe account that will receive funds sent out of the FeeVault -MIN_WITHDRAWAL_AMOUNTuint256The minimum amount of native asset held in the FeeVault before withdrawal is authorized -Fee Vault Configbytes32bytes32((WithdrawalNetwork << 248) || uint256(uint88(MIN_WITHDRAWAL_AMOUNT)) || uint256(uint160(RECIPIENT))) -BASE_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.basefeevaultconfig")) - 1)The Fee Vault Config for the BaseFeeVault -L1_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.l1feevaultconfig")) - 1)The Fee Vault Config for the L1FeeVault -SEQUENCER_FEE_VAULT_CONFIGbytes32(uint256(keccak256("opstack.sequencerfeevaultconfig")) - 1)The Fee Vault Config for the SequencerFeeVault -L1_CROSS_DOMAIN_MESSENGER_ADDRESSbytes32(uint256(keccak256("opstack.l1crossdomainmessengeraddress")) - 1)abi.encode(address(L1CrossDomainMessengerProxy)) -L1_ERC_721_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1erc721bridgeaddress")) - 1)abi.encode(address(L1ERC721BridgeProxy)) -L1_STANDARD_BRIDGE_ADDRESSbytes32(uint256(keccak256("opstack.l1standardbridgeaddress")) - 1)abi.encode(address(L1StandardBridgeProxy)) -REMOTE_CHAIN_IDbytes32(uint256(keccak256("opstack.remotechainid")) - 1)Chain ID of the remote chain - - -Predeploys -All network specific configuration is moved to a single contract, the L1Block predeploy. -All predeploys make calls to the L1Block contract to fetch network specific configuration -rather than reading it from local state. -graph LR - subgraph L1 - SystemConfig -- "setConfig(uint8,bytes)" --> OptimismPortal - end - subgraph L2 - L1Block - BaseFeeVault -- "baseFeeVaultConfig()(address,uint256,uint8)" --> L1Block - SequencerFeeVault -- "sequencerFeeVaultConfig()(address,uint256,uint8)" --> L1Block - L1FeeVault -- "l1FeeVaultConfig()(address,uint256,uint8)" --> L1Block - L2CrossDomainMessenger -- "l1CrossDomainMessenger()(address)" --> L1Block - L2StandardBridge -- "l1StandardBridge()(address)" --> L1Block - L2ERC721Bridge -- "l1ERC721Bridge()(address)" --> L1Block - OptimismMintableERC721Factory -- "remoteChainId()(uint256)" --> L1Block - end - OptimismPortal -- "setConfig(uint8,bytes)" --> L1Block - -L1Block -Storage -The following storage slots are defined: - -BASE_FEE_VAULT_CONFIG -L1_FEE_VAULT_CONFIG -SEQUENCER_FEE_VAULT_CONFIG -L1_CROSS_DOMAIN_MESSENGER_ADDRESS -L1_ERC_721_BRIDGE_ADDRESS -L1_STANDARD_BRIDGE_ADDRESS -REMOTE_CHAIN_ID - -Each slot MUST have a defined ConfigType that authorizes the setting of the storage slot -via a deposit transaction from the DEPOSITOR_ACCOUNT. -Interface -setHolocene -This function is meant to be called once on the activation block of the holocene network upgrade. -It MUST only be callable by the DEPOSITOR_ACCOUNT once. When it is called, it MUST call -call each getter for the network specific config and set the returndata into storage. -setConfig -This function MUST only be callable by the DEPOSITOR_ACCOUNT. It modifies the storage directly -of the L1Block contract. It MUST handle all defined ConfigTypes. To ensure a simple ABI, the -bytes value MUST be abi decoded based on the ConfigType. -function setConfig(ConfigType,bytes) - -Note that ConfigType is an enum which is an alias for a uint8. -baseFeeVaultConfig -This function MUST be called by the BaseFeeVault to fetch network specific configuration. -function baseFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -sequencerFeeVaultConfig -This function MUST be called by the SequencerFeeVault to fetch network specific configuration. -function sequencerFeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1FeeVaultConfig -This function MUST be called by the L1FeeVault to fetch network specific configuration. -function l1FeeVaultConfig()(address,uint256,WithdrawalNetwork) - -l1CrossDomainMessenger -This function MUST be called by the L2CrossDomainMessenger to fetch the address of the L1CrossDomainMessenger. -function l1CrossDomainMessenger()(address) - -l1StandardBridge -This function MUST be called by the L2StandardBridge to fetch the address of the L2CrossDomainMessenger. -function l1StandardBridge()(address) - -l1ERC721Bridge -This function MUST be called by the L2ERC721Bridge to fetch the address of the L1ERC721Bridge. -function l1ERC721Bridge()(address) - -remoteChainId -This function MUST be called by the OptimismMintableERC721Factory to fetch the chain id of the remote chain. -For an L2, this is the L1 chain id. -function remoteChainId()(uint256) - -FeeVault -The following changes apply to each of the BaseFeeVault, the L1FeeVault and the SequencerFeeVault. -Interface -The following functions are updated to read from the L1Block contract: - -recipient()(address) -withdrawalNetwork()(WithdrawalNetwork) -minWithdrawalAmount()(uint256) -withdraw() - -NameCall -BaseFeeVaultL1Block.baseFeeVaultConfig() -SequencerFeeVaultL1Block.sequencerFeeVaultConfig() -L1FeeVaultL1Block.l1FeeVaultConfig() - - -config -A new function is added to fetch the full Fee Vault Config. -function config()(address,uint256,WithdrawalNetwork) - -L2CrossDomainMessenger -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1CrossDomainMessenger(): - -otherMessenger()(address) -OTHER_MESSENGER()(address) - -L2ERC721Bridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1ERC721Bridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -L2StandardBridge -Interface -The following functions are updated to read from the L1Block contract by calling L1Block.l1StandardBridge() - -otherBridge()(address) -OTHER_BRIDGE()(address) - -OptimismMintableERC721Factory -The chain id is no longer read from storage but instead is read from the L1Block contract by calling -L1Block.remoteChainId() -Security Considerations -GovernanceToken -The predeploy defined by GovernanceToken should be an empty account until it is defined by -a future hardfork. +Predeploys @@ -401,7 +199,7 @@ GovernanceTok - + @@ -415,7 +213,7 @@ GovernanceTok - + diff --git a/protocol/holocene/configurability.html b/protocol/holocene/system-config.html similarity index 72% rename from protocol/holocene/configurability.html rename to protocol/holocene/system-config.html index 985283b56..0df792e3e 100644 --- a/protocol/holocene/configurability.html +++ b/protocol/holocene/system-config.html @@ -3,7 +3,7 @@ - Configurability - OP Stack Specification + System Config - OP Stack Specification @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary @@ -159,7 +159,7 @@ OP Stack Specification - + @@ -189,18 +189,12 @@ OP Stack Specification -Configurability +System Config Table of Contents -Overview -Constants - -ConfigType - - -SystemConfig +Overview ConfigUpdate Initialization @@ -214,22 +208,6 @@ Configurabili eip1559Denominator -Fee Vault Config - -setBaseFeeVaultConfig -setL1FeeVaultConfig -setSequencerFeeVaultConfig - - - - - - -OptimismPortal - -Interface - -setConfig @@ -237,23 +215,7 @@ Configurabili Overview -The SystemConfig and OptimismPortal are updated with a new flow for chain -configurability. -Constants -ConfigType -The ConfigType enum represents configuration that can be modified. -NameValueDescription -SET_GAS_PAYING_TOKENuint8(0)Modifies the gas paying token for the chain -SET_BASE_FEE_VAULT_CONFIGuint8(1)Sets the Fee Vault Config for the BaseFeeVault -SET_L1_FEE_VAULT_CONFIGuint8(2)Sets the Fee Vault Config for the L1FeeVault -SET_SEQUENCER_FEE_VAULT_CONFIGuint8(3)Sets the Fee Vault Config for the SequencerFeeVault -SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESSuint8(4)Sets the L1CrossDomainMessenger address -SET_L1_ERC_721_BRIDGE_ADDRESSuint8(5)Sets the L1ERC721Bridge address -SET_L1_STANDARD_BRIDGE_ADDRESSuint8(6)Sets the L1StandardBridge address -SET_REMOTE_CHAIN_IDuint8(7)Sets the chain id of the base chain - - -SystemConfig +The SystemConfig is updated to allow for dynamic EIP-1559 parameters. ConfigUpdate The following ConfigUpdate event is defined where the CONFIG_VERSION is uint256(0): NameValueDefinitionUsage @@ -272,16 +234,7 @@ Initialization< emit ConfigUpdate.GAS_LIMIT emit ConfigUpdate.UNSAFE_BLOCK_SIGNER emit ConfigUpdate.EIP_1559_PARAMS -setConfig(SET_GAS_PAYING_TOKEN) -setConfig(SET_BASE_FEE_VAULT_CONFIG) -setConfig(SET_L1_FEE_VAULT_CONFIG) -setConfig(SET_SEQUENCER_FEE_VAULT_CONFIG) -setConfig(SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESS) -setConfig(SET_L1_ERC_721_BRIDGE_ADDRESS) -setConfig(SET_L1_STANDARD_BRIDGE_ADDRESS) -setConfig(SET_REMOTE_CHAIN_ID) -These actions MAY only be triggered if there is a diff to the value. Modifying EIP-1559 Parameters A new SystemConfig UpdateType is introduced that enables the modification of EIP-1559 parameters. This allows for the chain @@ -302,39 +255,6 @@ e This function returns the currently configured EIP-1559 denominator. function eip1559Denominator()(uint64) -Fee Vault Config -For each FeeVault, there is a setter for its config. The arguments to the setter include -the RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork. -Each of these functions should be public and only callable by the chain governor. -Each function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType. -setBaseFeeVaultConfig -function setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork) - -setL1FeeVaultConfig -function setL1FeeVaultConfig(address,uint256,WithdrawalNetwork) - -setSequencerFeeVaultConfig -function setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork) - -OptimismPortal -The OptimismPortal is updated to emit a special system TransactionDeposited event. -Interface -setConfig -The setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig -is the single source of truth for chain operator ownership. -function setConfig(ConfigType,bytes) - -This function emits a TransactionDeposited event. -event TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData); - -The following fields are included: - -from is the DEPOSITOR_ACCOUNT -to is Predeploys.L1Block -version is uint256(0) -opaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit -is 200_000, isCreation is false and the data is abi.encodeCall(L1Block.setConfig, (_type, _value)) - diff --git a/protocol/messengers.html b/protocol/messengers.html index 5719b0eac..b0c6745a4 100644 --- a/protocol/messengers.html +++ b/protocol/messengers.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/overview.html b/protocol/overview.html index 19a171b6b..8d974911d 100644 --- a/protocol/overview.html +++ b/protocol/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/precompiles.html b/protocol/precompiles.html index 2636bcded..591225781 100644 --- a/protocol/precompiles.html +++ b/protocol/precompiles.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/predeploys.html b/protocol/predeploys.html index f69344d63..18f80ecc9 100644 --- a/protocol/predeploys.html +++ b/protocol/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/preinstalls.html b/protocol/preinstalls.html index a3e678702..de25cd1f4 100644 --- a/protocol/preinstalls.html +++ b/protocol/preinstalls.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/proposals.html b/protocol/proposals.html index 4356aed7b..c7e27aba0 100644 --- a/protocol/proposals.html +++ b/protocol/proposals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/regolith/overview.html b/protocol/regolith/overview.html index 25fb28a59..735c8d392 100644 --- a/protocol/regolith/overview.html +++ b/protocol/regolith/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node-p2p.html b/protocol/rollup-node-p2p.html index 6b7b877ad..f733fce32 100644 --- a/protocol/rollup-node-p2p.html +++ b/protocol/rollup-node-p2p.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node.html b/protocol/rollup-node.html index 7b2194855..74e7465df 100644 --- a/protocol/rollup-node.html +++ b/protocol/rollup-node.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/safe-extensions.html b/protocol/safe-extensions.html index c13615619..4601198ba 100644 --- a/protocol/safe-extensions.html +++ b/protocol/safe-extensions.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/stage-1.html b/protocol/stage-1.html index d28f06461..2659aa26c 100644 --- a/protocol/stage-1.html +++ b/protocol/stage-1.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-configuration.html b/protocol/superchain-configuration.html index ee7a3f560..6796bb40e 100644 --- a/protocol/superchain-configuration.html +++ b/protocol/superchain-configuration.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-upgrades.html b/protocol/superchain-upgrades.html index e9ac90b28..aad45a9b2 100644 --- a/protocol/superchain-upgrades.html +++ b/protocol/superchain-upgrades.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/system-config.html b/protocol/system-config.html index afbdefd92..d5fe843f1 100644 --- a/protocol/system-config.html +++ b/protocol/system-config.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/withdrawals.html b/protocol/withdrawals.html index e390c5450..8596661a9 100644 --- a/protocol/withdrawals.html +++ b/protocol/withdrawals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/root.html b/root.html index 20d712d67..bd978d50b 100644 --- a/root.html +++ b/root.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/searchindex.js b/searchindex.js index 371b06267..623744500 100644 --- a/searchindex.js +++ b/searchindex.js @@ -1 +1 @@ -Object.assign(window.search, {"doc_urls":["root.html#op-stack-specification","root.html#about-optimism","root.html#about-the-op-stack","root.html#site-navigation","background.html#background","background.html#overview","background.html#foundations","background.html#ethereum-scalability","background.html#optimistic-rollups","background.html#evm-equivalence","background.html#protocol-guarantees","background.html#liveness","background.html#validity","background.html#availability","background.html#network-participants","background.html#users","background.html#sequencers","background.html#verifiers","background.html#key-interaction-diagrams","background.html#depositing-and-sending-transactions","background.html#withdrawing","background.html#next-steps","protocol/overview.html#optimism-overview","protocol/overview.html#architecture-design-goals","protocol/overview.html#architecture-overview","protocol/overview.html#core-l1-smart-contracts","protocol/overview.html#core-l2-smart-contracts","protocol/overview.html#smart-contract-proxies","protocol/overview.html#l2-node-components","protocol/overview.html#transactionblock-propagation","protocol/overview.html#key-interactions-in-depth","protocol/overview.html#deposits","protocol/overview.html#block-derivation","protocol/overview.html#engine-api","protocol/bridges.html#standard-bridges","protocol/bridges.html#overview","protocol/bridges.html#token-depositing","protocol/bridges.html#upgradability","protocol/messengers.html#cross-domain-messengers","protocol/messengers.html#overview","protocol/messengers.html#message-passing","protocol/messengers.html#upgradability","protocol/messengers.html#message-versioning","protocol/messengers.html#message-version-0","protocol/messengers.html#message-version-1","protocol/messengers.html#backwards-compatibility-notes","protocol/deposits.html#deposits","protocol/deposits.html#overview","protocol/deposits.html#the-deposited-transaction-type","protocol/deposits.html#source-hash-computation","protocol/deposits.html#kinds-of-deposited-transactions","protocol/deposits.html#validation-and-authorization-of-deposited-transactions","protocol/deposits.html#execution","protocol/deposits.html#deposit-receipt","protocol/deposits.html#l1-attributes-deposited-transaction","protocol/deposits.html#l1-attributes-deposited-transaction-calldata","protocol/deposits.html#special-accounts-on-l2","protocol/deposits.html#l1-attributes-depositor-account","protocol/deposits.html#l1-attributes-predeployed-contract","protocol/deposits.html#user-deposited-transactions","protocol/deposits.html#deposit-contract","protocol/withdrawals.html#withdrawals","protocol/withdrawals.html#overview","protocol/withdrawals.html#withdrawal-flow","protocol/withdrawals.html#on-l2","protocol/withdrawals.html#on-l1","protocol/withdrawals.html#the-l2tol1messagepasser-contract","protocol/withdrawals.html#addresses-are-not-aliased-on-withdrawals","protocol/withdrawals.html#the-optimism-portal-contract","protocol/withdrawals.html#withdrawal-verification-and-finalization","protocol/withdrawals.html#security-considerations","protocol/withdrawals.html#key-properties-of-withdrawal-verification","protocol/withdrawals.html#handling-successfully-verified-messages-that-fail-when-relayed","protocol/withdrawals.html#optimismportal-can-send-arbitrary-messages-on-l1","protocol/guaranteed-gas-market.html#guaranteed-gas-fee-market","protocol/guaranteed-gas-market.html#overview","protocol/guaranteed-gas-market.html#gas-stipend","protocol/guaranteed-gas-market.html#default-values","protocol/guaranteed-gas-market.html#limiting-guaranteed-gas","protocol/guaranteed-gas-market.html#rationale-for-burning-l1-gas","protocol/guaranteed-gas-market.html#on-preventing-griefing-attacks","protocol/proposals.html#l2-output-root-proposals-specification","protocol/proposals.html#overview","protocol/proposals.html#proposing-l2-output-commitments","protocol/proposals.html#l2outputoracle-v100","protocol/proposals.html#l2-output-commitment-construction","protocol/proposals.html#l2-output-oracle-smart-contract","protocol/proposals.html#configuration","protocol/proposals.html#security-considerations","protocol/proposals.html#l1-reorgs","protocol/exec-engine.html#l2-execution-engine","protocol/exec-engine.html#1559-parameters","protocol/exec-engine.html#deposited-transaction-processing","protocol/exec-engine.html#deposited-transaction-boundaries","protocol/exec-engine.html#fees","protocol/exec-engine.html#fee-vaults","protocol/exec-engine.html#priority-fees-sequencer-fee-vault","protocol/exec-engine.html#base-fees-base-fee-vault","protocol/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/exec-engine.html#engine-api","protocol/exec-engine.html#engine_forkchoiceupdatedv2","protocol/exec-engine.html#engine_forkchoiceupdatedv3","protocol/exec-engine.html#engine_newpayloadv2","protocol/exec-engine.html#engine_newpayloadv3","protocol/exec-engine.html#engine_getpayloadv2","protocol/exec-engine.html#engine_getpayloadv3","protocol/exec-engine.html#engine_signalsuperchainv1","protocol/exec-engine.html#networking","protocol/exec-engine.html#sync","protocol/exec-engine.html#happy-path-sync","protocol/exec-engine.html#worst-case-sync","protocol/exec-engine.html#ecotone-disable-blob-transactions","protocol/exec-engine.html#ecotone-beacon-block-root","protocol/exec-engine.html#p2p-modifications","protocol/rollup-node.html#rollup-node-specification","protocol/rollup-node.html#overview","protocol/rollup-node.html#driver","protocol/rollup-node.html#derivation","protocol/rollup-node.html#l2-output-rpc-method","protocol/rollup-node.html#structures","protocol/rollup-node.html#output-method-api","protocol/rollup-node.html#protocol-version-tracking","protocol/rollup-node-p2p.html#rollup-node-p2p-interface","protocol/rollup-node-p2p.html#overview","protocol/rollup-node-p2p.html#p2p-configuration","protocol/rollup-node-p2p.html#identification","protocol/rollup-node-p2p.html#discv5","protocol/rollup-node-p2p.html#libp2p","protocol/rollup-node-p2p.html#gossip-topics","protocol/rollup-node-p2p.html#blocksv1","protocol/rollup-node-p2p.html#blocksv2","protocol/rollup-node-p2p.html#blocksv3","protocol/rollup-node-p2p.html#block-encoding","protocol/rollup-node-p2p.html#block-signatures","protocol/rollup-node-p2p.html#block-validation","protocol/rollup-node-p2p.html#req-resp","protocol/rollup-node-p2p.html#payload_by_number","protocol/derivation.html#l2-chain-derivation-specification","protocol/derivation.html#overview","protocol/derivation.html#eager-block-derivation","protocol/derivation.html#protocol-parameters","protocol/derivation.html#batch-submission","protocol/derivation.html#sequencing--batch-submission-overview","protocol/derivation.html#batch-submission-wire-format","protocol/derivation.html#batcher-transaction-format","protocol/derivation.html#frame-format","protocol/derivation.html#channel-format","protocol/derivation.html#batch-format","protocol/derivation.html#architecture","protocol/derivation.html#l2-chain-derivation-pipeline","protocol/derivation.html#l1-traversal","protocol/derivation.html#l1-retrieval","protocol/derivation.html#frame-queue","protocol/derivation.html#channel-bank","protocol/derivation.html#channel-reader-batch-decoding","protocol/derivation.html#batch-queue","protocol/derivation.html#payload-attributes-derivation","protocol/derivation.html#engine-queue","protocol/derivation.html#resetting-the-pipeline","protocol/derivation.html#deriving-payload-attributes","protocol/derivation.html#deriving-the-transaction-list","protocol/derivation.html#network-upgrade-automation-transactions","protocol/derivation.html#building-individual-payload-attributes","protocol/batcher.html#batch-submitter","protocol/batcher.html#overview","fault-proof/index.html#fault-proof","fault-proof/index.html#overview","fault-proof/index.html#pre-image-oracle","fault-proof/index.html#pre-image-key-types","fault-proof/index.html#bootstrapping","fault-proof/index.html#hinting","fault-proof/index.html#pre-image-communication","fault-proof/index.html#fault-proof-program","fault-proof/index.html#prologue","fault-proof/index.html#main-content","fault-proof/index.html#epilogue","fault-proof/index.html#pre-image-hinting-routes","fault-proof/index.html#precompile-accelerators","fault-proof/index.html#fault-proof-vm","fault-proof/index.html#fault-proof-interactive-dispute-game","fault-proof/cannon-fault-proof-vm.html#cannon-fault-proof-virtual-machine","fault-proof/cannon-fault-proof-vm.html#overview","fault-proof/cannon-fault-proof-vm.html#state","fault-proof/cannon-fault-proof-vm.html#state-hash","fault-proof/cannon-fault-proof-vm.html#memory","fault-proof/cannon-fault-proof-vm.html#heap","fault-proof/cannon-fault-proof-vm.html#delay-slots","fault-proof/cannon-fault-proof-vm.html#syscalls","fault-proof/cannon-fault-proof-vm.html#io","fault-proof/cannon-fault-proof-vm.html#standard-streams","fault-proof/cannon-fault-proof-vm.html#hint-communication","fault-proof/cannon-fault-proof-vm.html#pre-image-communication","fault-proof/cannon-fault-proof-vm.html#exceptions","fault-proof/cannon-fault-proof-vm.html#security-model","fault-proof/cannon-fault-proof-vm.html#compiler-correctness","fault-proof/cannon-fault-proof-vm.html#compiler-assumptions","fault-proof/stage-one/index.html#stage-one-decentralization","fault-proof/stage-one/dispute-game-interface.html#dispute-game-interface","fault-proof/stage-one/dispute-game-interface.html#overview","fault-proof/stage-one/dispute-game-interface.html#types","fault-proof/stage-one/dispute-game-interface.html#disputegamefactory-interface","fault-proof/stage-one/dispute-game-interface.html#disputegame-interface","fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game","fault-proof/stage-one/fault-dispute-game.html#overview","fault-proof/stage-one/fault-dispute-game.html#definitions","fault-proof/stage-one/fault-dispute-game.html#virtual-machine-vm","fault-proof/stage-one/fault-dispute-game.html#preimageoracle","fault-proof/stage-one/fault-dispute-game.html#execution-trace","fault-proof/stage-one/fault-dispute-game.html#claims","fault-proof/stage-one/fault-dispute-game.html#anchor-state","fault-proof/stage-one/fault-dispute-game.html#anchor-state-registry","fault-proof/stage-one/fault-dispute-game.html#dag","fault-proof/stage-one/fault-dispute-game.html#subgame","fault-proof/stage-one/fault-dispute-game.html#game-tree","fault-proof/stage-one/fault-dispute-game.html#position","fault-proof/stage-one/fault-dispute-game.html#max_clock_duration","fault-proof/stage-one/fault-dispute-game.html#clock_extension","fault-proof/stage-one/fault-dispute-game.html#freeloader-claims","fault-proof/stage-one/fault-dispute-game.html#core-game-mechanics","fault-proof/stage-one/fault-dispute-game.html#actors","fault-proof/stage-one/fault-dispute-game.html#moves","fault-proof/stage-one/fault-dispute-game.html#l2-block-number-challenge","fault-proof/stage-one/fault-dispute-game.html#step","fault-proof/stage-one/fault-dispute-game.html#step-types","fault-proof/stage-one/fault-dispute-game.html#preimageoracle-interaction","fault-proof/stage-one/fault-dispute-game.html#team-dynamics","fault-proof/stage-one/fault-dispute-game.html#game-clock","fault-proof/stage-one/fault-dispute-game.html#resolution","fault-proof/stage-one/fault-dispute-game.html#finalization","fault-proof/stage-one/honest-challenger-fdg.html#honest-challenger-fault-dispute-game","fault-proof/stage-one/honest-challenger-fdg.html#overview","fault-proof/stage-one/honest-challenger-fdg.html#invariants","fault-proof/stage-one/honest-challenger-fdg.html#fault-dispute-game-responses","fault-proof/stage-one/honest-challenger-fdg.html#moves","fault-proof/stage-one/honest-challenger-fdg.html#steps","fault-proof/stage-one/honest-challenger-fdg.html#timeliness","fault-proof/stage-one/honest-challenger-fdg.html#resolution","fault-proof/stage-one/bond-incentives.html#bond-incentives","fault-proof/stage-one/bond-incentives.html#overview","fault-proof/stage-one/bond-incentives.html#moves","fault-proof/stage-one/bond-incentives.html#subgame-resolution","fault-proof/stage-one/bond-incentives.html#leftmost-claim-incentives","fault-proof/stage-one/bond-incentives.html#fault-proof-mainnet-incentives","fault-proof/stage-one/bond-incentives.html#authenticated-roles","fault-proof/stage-one/bond-incentives.html#base-fee-assumption","fault-proof/stage-one/bond-incentives.html#bond-scaling","fault-proof/stage-one/bond-incentives.html#required-bond-formula","fault-proof/stage-one/bond-incentives.html#other-incentives","fault-proof/stage-one/bond-incentives.html#delayedweth","fault-proof/stage-one/bridge-integration.html#bridge-integration","fault-proof/stage-one/bridge-integration.html#overview","fault-proof/stage-one/bridge-integration.html#legacy-semantics","fault-proof/stage-one/bridge-integration.html#fpac-optimismportal-mods-specification","fault-proof/stage-one/bridge-integration.html#roles---optimismportal","fault-proof/stage-one/bridge-integration.html#new-deployconfig-variables","fault-proof/stage-one/bridge-integration.html#data-structures","fault-proof/stage-one/bridge-integration.html#state-layout","fault-proof/stage-one/bridge-integration.html#provewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#finalizewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#air-gap","fault-proof/stage-one/bridge-integration.html#proxy-upgrade","fault-proof/stage-one/bridge-integration.html#permissioned-faultdisputegame","fault-proof/stage-one/bridge-integration.html#roles---permissioneddisputegame","fault-proof/stage-one/bridge-integration.html#modifications","protocol/precompiles.html#precompiles","protocol/precompiles.html#overview","protocol/precompiles.html#p256verify","protocol/predeploys.html#predeploys","protocol/predeploys.html#overview","protocol/predeploys.html#legacymessagepasser","protocol/predeploys.html#l2tol1messagepasser","protocol/predeploys.html#deployerwhitelist","protocol/predeploys.html#legacyerc20eth","protocol/predeploys.html#weth9","protocol/predeploys.html#l2crossdomainmessenger","protocol/predeploys.html#l2standardbridge","protocol/predeploys.html#l1blocknumber","protocol/predeploys.html#gaspriceoracle","protocol/predeploys.html#l1block","protocol/predeploys.html#proxyadmin","protocol/predeploys.html#sequencerfeevault","protocol/predeploys.html#optimismmintableerc20factory","protocol/predeploys.html#optimismmintableerc721factory","protocol/predeploys.html#basefeevault","protocol/predeploys.html#l1feevault","protocol/predeploys.html#schemaregistry","protocol/predeploys.html#eas","protocol/predeploys.html#beacon-block-root","protocol/preinstalls.html#preinstalls","protocol/preinstalls.html#overview","protocol/preinstalls.html#safe","protocol/preinstalls.html#safel2","protocol/preinstalls.html#multisend","protocol/preinstalls.html#multisendcallonly","protocol/preinstalls.html#safesingletonfactory","protocol/preinstalls.html#multicall3","protocol/preinstalls.html#create2deployer","protocol/preinstalls.html#createx","protocol/preinstalls.html#arachnids-deterministic-deployment-proxy","protocol/preinstalls.html#permit2","protocol/preinstalls.html#erc-4337-v060-entrypoint","protocol/preinstalls.html#erc-4337-v060-sendercreator","protocol/preinstalls.html#erc-4337-v070-entrypoint","protocol/preinstalls.html#erc-4337-v070-sendercreator","protocol/superchain-configuration.html#superchain-configuration","protocol/superchain-configuration.html#overview","protocol/superchain-configuration.html#configurable-values","protocol/superchain-configuration.html#configuration-data-flow","protocol/superchain-configuration.html#pausability","protocol/superchain-upgrades.html#superchain-upgrades","protocol/superchain-upgrades.html#overview","protocol/superchain-upgrades.html#protocol-version","protocol/superchain-upgrades.html#protocol-version-format","protocol/superchain-upgrades.html#protocol-version-exposure","protocol/superchain-upgrades.html#superchain-target","protocol/superchain-upgrades.html#superchain-version-signaling","protocol/superchain-upgrades.html#protocolversions-l1-contract","protocol/superchain-upgrades.html#activation-rules","protocol/superchain-upgrades.html#l2-block-number-based-activation-deprecated","protocol/superchain-upgrades.html#l2-block-timestamp-based-activation","protocol/superchain-upgrades.html#op-stack-protocol-versions","protocol/superchain-upgrades.html#post-bedrock-network-upgrades","protocol/superchain-upgrades.html#activation-timestamps","protocol/system-config.html#system-config","protocol/system-config.html#overview","protocol/system-config.html#system-config-contents-version-0","protocol/system-config.html#batcherhash-bytes32","protocol/system-config.html#scalars","protocol/system-config.html#gaslimit-uint64","protocol/system-config.html#unsafeblocksigner-address","protocol/system-config.html#writing-the-system-config","protocol/system-config.html#reading-the-system-config","protocol/configurability.html#op-stack-configurability","protocol/configurability.html#consensus-parameters","protocol/configurability.html#batch-inbox-address","protocol/configurability.html#batcher-hash","protocol/configurability.html#chain-id","protocol/configurability.html#proof-maturity-delay","protocol/configurability.html#dispute-game-finality","protocol/configurability.html#respected-game-type","protocol/configurability.html#fault-game-max-depth","protocol/configurability.html#fault-game-split-depth","protocol/configurability.html#max-game-clock-duration","protocol/configurability.html#game-clock-extension","protocol/configurability.html#bond-withdrawal-delay","protocol/configurability.html#minimum-large-preimage-proposal-size","protocol/configurability.html#large-preimage-proposal-challenge-period","protocol/configurability.html#fault-game-absolute-prestate","protocol/configurability.html#fault-game-genesis-block","protocol/configurability.html#fault-game-genesis-output-root","protocol/configurability.html#fee-scalar","protocol/configurability.html#gas-limit","protocol/configurability.html#genesis-state","protocol/configurability.html#l2-block-time","protocol/configurability.html#resource-config","protocol/configurability.html#sequencing-window-size","protocol/configurability.html#start-block","protocol/configurability.html#superchain-target","protocol/configurability.html#governance-token","protocol/configurability.html#resource-config-1","protocol/configurability.html#policy-parameters","protocol/configurability.html#data-availability-type","protocol/configurability.html#batch-submission-frequency","protocol/configurability.html#output-frequency","protocol/configurability.html#admin-roles","protocol/configurability.html#l1-proxy-admin","protocol/configurability.html#l1-proxyadmin-owner","protocol/configurability.html#l2-proxy-admin","protocol/configurability.html#l2-proxyadmin-owner","protocol/configurability.html#system-config-owner","protocol/configurability.html#service-roles","protocol/configurability.html#batch-submitter-address","protocol/configurability.html#challenger-address","protocol/configurability.html#guardian-address","protocol/configurability.html#proposer-address","protocol/configurability.html#sequencer-p2p--unsafe-head-signer","protocol/safe-extensions.html#safe-contract-extensions","protocol/safe-extensions.html#guardian-safe","protocol/safe-extensions.html#deputy-guardian-module","protocol/safe-extensions.html#deputy-guardian-module-security-properties","protocol/safe-extensions.html#security-council-liveness-checking-extensions","protocol/safe-extensions.html#the-liveness-guard","protocol/safe-extensions.html#the-liveness-module","protocol/safe-extensions.html#owner-removal-call-flow","protocol/safe-extensions.html#shutdown","protocol/safe-extensions.html#liveness-security-properties","protocol/safe-extensions.html#interdependency-between-the-liveness-guard-and-liveness-module","protocol/safe-extensions.html#operational-considerations","protocol/safe-extensions.html#manual-validation-of-new-owner-liveness","protocol/safe-extensions.html#deploying-the-liveness-checking-system","protocol/safe-extensions.html#modifying-the-liveness-checking-system","protocol/stage-1.html#stage-1-roles-and-requirements","protocol/stage-1.html#overview","protocol/stage-1.html#permissionless-fault-proofs","protocol/stage-1.html#roles-for-stage-1","protocol/stage-1.html#configuration-of-safes","protocol/stage-1.html#ownership-model-diagram","protocol/regolith/overview.html#regolith","protocol/regolith/overview.html#overview","protocol/canyon/overview.html#canyon","protocol/canyon/overview.html#execution-layer","protocol/canyon/overview.html#consensus-layer","protocol/delta/overview.html#delta","protocol/delta/overview.html#consensus-layer","protocol/delta/span-batches.html#span-batches","protocol/delta/span-batches.html#introduction","protocol/delta/span-batches.html#span-batch-format","protocol/delta/span-batches.html#span-batch-size-limits","protocol/delta/span-batches.html#future-batch-format-extension","protocol/delta/span-batches.html#span-batch-activation-rule","protocol/delta/span-batches.html#optimization-strategies","protocol/delta/span-batches.html#truncating-information-and-storing-only-necessary-data","protocol/delta/span-batches.html#tx_data_headers-removal-from-initial-specs","protocol/delta/span-batches.html#chain-id-removal-from-initial-specs","protocol/delta/span-batches.html#reorganization-of-constant-length-transaction-fields","protocol/delta/span-batches.html#rlp-encoding-for-only-variable-length-fields","protocol/delta/span-batches.html#store-y_parity-and-protected_bit-instead-of-v","protocol/delta/span-batches.html#adjust-txs-data-layout-for-better-compression","protocol/delta/span-batches.html#fee_recipients-encoding-scheme","protocol/delta/span-batches.html#how-derivation-works-with-span-batches","protocol/delta/span-batches.html#integration","protocol/delta/span-batches.html#channel-reader-batch-decoding","protocol/delta/span-batches.html#batch-queue","protocol/delta/span-batches.html#batcher","protocol/ecotone/overview.html#ecotone-network-upgrade","protocol/ecotone/overview.html#execution-layer","protocol/ecotone/overview.html#consensus-layer","protocol/ecotone/derivation.html#derivation","protocol/ecotone/derivation.html#ecotone-blob-retrieval","protocol/ecotone/derivation.html#blob-encoding","protocol/ecotone/l1-attributes.html#ecotone-l1-attributes","protocol/ecotone/l1-attributes.html#overview","protocol/ecotone/l1-attributes.html#l1-attributes-predeployed-contract","protocol/ecotone/l1-attributes.html#ecotone-l1block-upgrade","protocol/fjord/overview.html#fjord-network-upgrade","protocol/fjord/overview.html#execution-layer","protocol/fjord/overview.html#consensus-layer","protocol/fjord/exec-engine.html#l2-execution-engine","protocol/fjord/exec-engine.html#fees","protocol/fjord/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/fjord/exec-engine.html#l1-gas-usage-estimation","protocol/fjord/derivation.html#fjord-l2-chain-derivation-changes","protocol/fjord/derivation.html#protocol-parameter-changes","protocol/fjord/derivation.html#timestamp-activation","protocol/fjord/derivation.html#constant-maximum-sequencer-drift","protocol/fjord/derivation.html#rationale","protocol/fjord/derivation.html#security-considerations","protocol/fjord/derivation.html#increasing-max_rlp_bytes_per_channel-and-max_channel_bank_size","protocol/fjord/derivation.html#rationale-1","protocol/fjord/derivation.html#security-considerations-1","protocol/fjord/derivation.html#brotli-channel-compression","protocol/fjord/derivation.html#network-upgrade-automation-transactions","protocol/fjord/derivation.html#gaspriceoracle-deployment","protocol/fjord/derivation.html#gaspriceoracle-proxy-update","protocol/fjord/derivation.html#gaspriceoracle-enable-fjord","protocol/fjord/predeploys.html#predeploys","protocol/fjord/predeploys.html#gaspriceoracle","protocol/fjord/predeploys.html#l1-gas-usage-estimation","protocol/granite/overview.html#granite-network-upgrade","protocol/granite/overview.html#execution-layer","protocol/granite/overview.html#consensus-layer","protocol/granite/exec-engine.html#l2-execution-engine","protocol/granite/exec-engine.html#evm-changes","protocol/granite/exec-engine.html#bn256pairing-precompile-input-restriction","protocol/granite/derivation.html#granite-l2-chain-derivation-changes","protocol/granite/derivation.html#protocol-parameter-changes","protocol/granite/derivation.html#reduce-channel-timeout","protocol/holocene/overview.html#holocene-network-upgrade","protocol/holocene/overview.html#execution-layer","protocol/holocene/overview.html#consensus-layer","protocol/holocene/overview.html#smart-contracts","protocol/holocene/derivation.html#holocene-l2-chain-derivation-changes","protocol/holocene/derivation.html#holocene-derivation","protocol/holocene/derivation.html#summary","protocol/holocene/derivation.html#frame-queue","protocol/holocene/derivation.html#channel-bank","protocol/holocene/derivation.html#pruning","protocol/holocene/derivation.html#timeout","protocol/holocene/derivation.html#reading--frame-loading","protocol/holocene/derivation.html#span-batches","protocol/holocene/derivation.html#batch-queue","protocol/holocene/derivation.html#fast-channel-invalidation","protocol/holocene/derivation.html#engine-queue","protocol/holocene/derivation.html#attributes-builder","protocol/holocene/derivation.html#activation","protocol/holocene/derivation.html#rationale","protocol/holocene/derivation.html#strict-frame-and-batch-ordering","protocol/holocene/derivation.html#partial-span-batch-validity","protocol/holocene/derivation.html#fast-channel-invalidation-1","protocol/holocene/derivation.html#steady-block-derivation","protocol/holocene/derivation.html#less-defensive-protocol","protocol/holocene/derivation.html#security-and-implementation-considerations","protocol/holocene/derivation.html#reorgs","protocol/holocene/derivation.html#batcher-hardening","protocol/holocene/derivation.html#sync-start","protocol/holocene/exec-engine.html#l2-execution-engine","protocol/holocene/exec-engine.html#timestamp-activation","protocol/holocene/exec-engine.html#l2tol1messagepasser-storage-root-in-header","protocol/holocene/exec-engine.html#header-validity-rules","protocol/holocene/exec-engine.html#header-withdrawals-root","protocol/holocene/exec-engine.html#extended-payloadattributesv3","protocol/holocene/exec-engine.html#eip1559params-encoding","protocol/holocene/exec-engine.html#execution","protocol/holocene/exec-engine.html#rationale","protocol/holocene/exec-engine.html#eip1559params-in-header","protocol/holocene/exec-engine.html#header-validity-rules-1","protocol/holocene/exec-engine.html#encoding","protocol/holocene/exec-engine.html#rationale-1","protocol/holocene/predeploys.html#overview","protocol/holocene/predeploys.html#constants","protocol/holocene/predeploys.html#predeploys","protocol/holocene/predeploys.html#l1block","protocol/holocene/predeploys.html#feevault","protocol/holocene/predeploys.html#l2crossdomainmessenger","protocol/holocene/predeploys.html#l2erc721bridge","protocol/holocene/predeploys.html#l2standardbridge","protocol/holocene/predeploys.html#optimismmintableerc721factory","protocol/holocene/predeploys.html#security-considerations","protocol/holocene/predeploys.html#governancetoken","protocol/holocene/configurability.html#configurability","protocol/holocene/configurability.html#overview","protocol/holocene/configurability.html#constants","protocol/holocene/configurability.html#configtype","protocol/holocene/configurability.html#systemconfig","protocol/holocene/configurability.html#configupdate","protocol/holocene/configurability.html#initialization","protocol/holocene/configurability.html#modifying-eip-1559-parameters","protocol/holocene/configurability.html#interface","protocol/holocene/configurability.html#optimismportal","protocol/holocene/configurability.html#interface-1","governance/gov-token.html#governance-token","governance/gov-token.html#overview","governance/gov-token.html#token-minting","governance/gov-token.html#token-burning","governance/gov-token.html#voting-power","governance/gov-token.html#delegation","experimental/custom-gas-token.html#custom-gas-token","experimental/custom-gas-token.html#overview","experimental/custom-gas-token.html#constants","experimental/custom-gas-token.html#properties-of-a-gas-paying-token","experimental/custom-gas-token.html#automated-validation","experimental/custom-gas-token.html#configuring-the-gas-paying-token","experimental/custom-gas-token.html#contract-modifications","experimental/custom-gas-token.html#igastoken-interface","experimental/custom-gas-token.html#gas-token-aware","experimental/custom-gas-token.html#optimismportal","experimental/custom-gas-token.html#standardbridge","experimental/custom-gas-token.html#crossdomainmessenger","experimental/custom-gas-token.html#systemconfig","experimental/custom-gas-token.html#l1block","experimental/custom-gas-token.html#weth9","experimental/custom-gas-token.html#user-flow","experimental/custom-gas-token.html#when-eth-is-the-native-asset","experimental/custom-gas-token.html#when-an-erc20-token-is-the-native-asset","experimental/custom-gas-token.html#differences","experimental/custom-gas-token.html#upgrade","experimental/custom-gas-token.html#l1block-deployment","experimental/custom-gas-token.html#l2crossdomainmessenger-deployment","experimental/custom-gas-token.html#l2standardbridge-deployment","experimental/custom-gas-token.html#l1block-proxy-update","experimental/custom-gas-token.html#l2crossdomainmessenger-proxy-update","experimental/custom-gas-token.html#l2standardbridge-proxy-update","experimental/custom-gas-token.html#selection-of-ether_token_address","experimental/custom-gas-token.html#standard-config","experimental/custom-gas-token.html#fees","experimental/custom-gas-token.html#security-considerations","experimental/custom-gas-token.html#optimismportal-token-allowance","experimental/custom-gas-token.html#interoperability-support","experimental/custom-gas-token.html#wrapped-ether","experimental/alt-da.html#alt-da-mode","experimental/alt-da.html#overview","experimental/alt-da.html#input-commitment-submission","experimental/alt-da.html#da-server","experimental/alt-da.html#data-availability-challenge-contract","experimental/alt-da.html#parameters","experimental/alt-da.html#derivation","experimental/alt-da.html#fault-proof","experimental/alt-da.html#l2-input","experimental/alt-da.html#l1-challenge-status","experimental/alt-da.html#safety-and-finality","experimental/alt-da.html#security-considerations","interop/overview.html#interop","interop/overview.html#specifications","interop/dependency-set.html#the-dependency-set","interop/dependency-set.html#chain-id","interop/dependency-set.html#updating-the-dependency-set","interop/dependency-set.html#security-considerations","interop/dependency-set.html#layer-1-as-part-of-the-dependency-set","interop/messaging.html#messaging","interop/messaging.html#message","interop/messaging.html#message-payload","interop/messaging.html#message-identifier","interop/messaging.html#messaging-ends","interop/messaging.html#initiating-messages","interop/messaging.html#executing-messages","interop/messaging.html#messaging-invariants","interop/messaging.html#timestamp-invariant","interop/messaging.html#chainid-invariant","interop/messaging.html#message-expiry-invariant","interop/messaging.html#message-graph","interop/messaging.html#invalid-messages","interop/messaging.html#intra-block-messaging-cycles","interop/messaging.html#resolving-cross-chain-safety","interop/messaging.html#horizon-timestamp","interop/messaging.html#pruning-the-graph","interop/messaging.html#bounding-the-graph","interop/messaging.html#security-considerations","interop/messaging.html#cyclic-dependencies","interop/messaging.html#transitive-dependencies","interop/predeploys.html#predeploys","interop/predeploys.html#crossl2inbox","interop/predeploys.html#functions","interop/predeploys.html#interop-start-timestamp","interop/predeploys.html#executingmessage-event","interop/predeploys.html#reference-implementation","interop/predeploys.html#deposit-handling","interop/predeploys.html#identifier-getters","interop/predeploys.html#l2tol2crossdomainmessenger","interop/predeploys.html#relaymessage-invariants","interop/predeploys.html#sendexpire-invariants","interop/predeploys.html#relayexpire-invariants","interop/predeploys.html#message-versioning","interop/predeploys.html#no-native-support-for-cross-chain-ether-sends","interop/predeploys.html#interfaces","interop/predeploys.html#optimismsuperchainerc20factory","interop/predeploys.html#optimismsuperchainerc20","interop/predeploys.html#overview","interop/predeploys.html#functions-1","interop/predeploys.html#events","interop/predeploys.html#deployment-flow","interop/predeploys.html#beaconcontract","interop/predeploys.html#overview-1","interop/predeploys.html#l1block","interop/predeploys.html#static-configuration","interop/predeploys.html#dependency-set","interop/predeploys.html#deposit-context","interop/predeploys.html#isdeposit","interop/predeploys.html#optimismmintableerc20factory","interop/predeploys.html#optimismmintableerc20","interop/predeploys.html#updates","interop/predeploys.html#functions-2","interop/predeploys.html#events-1","interop/predeploys.html#l2standardbridge","interop/predeploys.html#updates-1","interop/predeploys.html#invariants","interop/predeploys.html#conversion-flow","interop/predeploys.html#superchainerc20bridge","interop/predeploys.html#overview-2","interop/predeploys.html#functions-3","interop/predeploys.html#events-2","interop/predeploys.html#diagram","interop/predeploys.html#invariants-1","interop/predeploys.html#security-considerations","interop/sequencer.html#sequencer","interop/sequencer.html#sequencer-policy","interop/sequencer.html#block-building","interop/sequencer.html#static-analysis","interop/sequencer.html#dependency-confirmations","interop/sequencer.html#sponsorship","interop/sequencer.html#security-considerations","interop/sequencer.html#cross-chain-message-latency","interop/verifier.html#verifier","interop/verifier.html#derivation-pipeline","interop/verifier.html#depositing-an-executing-message","interop/verifier.html#safety","interop/verifier.html#honest-verifier","interop/verifier.html#security-considerations","interop/verifier.html#forced-inclusion-of-cross-chain-messages","interop/verifier.html#reliance-on-history","interop/rollup-node-p2p.html#p2p-networking","interop/rollup-node-p2p.html#security-considerations","interop/fault-proof.html#fault-proof","interop/fault-proof.html#cascading-dependencies","interop/fault-proof.html#security-considerations","interop/upgrade.html#interop-network-upgrade","interop/upgrade.html#l1-attributes","interop/upgrade.html#l1-attributes-predeployed-contract","interop/upgrade.html#interop-l1block-upgrade","interop/upgrade.html#security-considerations","interop/token-bridging.html#token-bridging","interop/token-bridging.html#overview","interop/token-bridging.html#superchainerc20-standard","interop/token-bridging.html#properties","interop/token-bridging.html#interface","interop/token-bridging.html#superchainerc20bridge","interop/token-bridging.html#diagram","interop/token-bridging.html#implementation","interop/token-bridging.html#future-considerations","interop/token-bridging.html#cross-chain-transferfrom","interop/token-bridging.html#concatenated-action","interop/superchain-weth.html#superchain-weth","interop/superchain-weth.html#motivation-and-constraints","interop/superchain-weth.html#handling-native-assets-other-than-eth","interop/superchain-weth.html#minimizing-protocol-complexity","interop/superchain-weth.html#constants","interop/superchain-weth.html#superchainweth","interop/superchain-weth.html#invariants","interop/superchain-weth.html#ethliquidity","interop/superchain-weth.html#invariants-1","interop/derivation.html#derivation","interop/derivation.html#overview","interop/derivation.html#deposit-context","interop/derivation.html#security-considerations","interop/derivation.html#gas-considerations","interop/tx-pool.html#transaction-pool","interop/tx-pool.html#message-validation","interop/tx-pool.html#system-deposits-transaction-margin","interop/tx-pool.html#security-considerations","interop/tx-pool.html#mempool-denial-of-service","experimental/op-contracts-manager.html#op-contracts-manager","experimental/op-contracts-manager.html#deployment","experimental/op-contracts-manager.html#interface","experimental/op-contracts-manager.html#proxysol","experimental/op-contracts-manager.html#deploy","experimental/op-contracts-manager.html#getter-methods","experimental/op-contracts-manager.html#implementation","experimental/op-contracts-manager.html#batch-inbox-address","experimental/op-contracts-manager.html#contract-deployments","experimental/op-contracts-manager.html#security-considerations","experimental/op-contracts-manager.html#chain-id-source-of-truth","experimental/op-contracts-manager.html#chain-id-frontrunning","experimental/op-contracts-manager.html#chain-id-value","experimental/op-contracts-manager.html#proxy-admin-owner","experimental/op-contracts-manager.html#upgradeability-abi-changes","experimental/gov-token.html#governance-token","experimental/gov-token.html#overview","experimental/gov-token.html#hook-based-integration-with-governancedelegation","experimental/gov-token.html#token-minting","experimental/gov-token.html#token-burning","experimental/gov-token.html#voting-power","experimental/gov-token.html#delegation","glossary.html#glossary","glossary.html#general-terms","glossary.html#layer-1-l1","glossary.html#layer-2-l2","glossary.html#block","glossary.html#eoa","glossary.html#merkle-patricia-trie","glossary.html#chain-re-organization","glossary.html#predeployed-contract-predeploy","glossary.html#preinstalled-contract-preinstall","glossary.html#precompiled-contract-precompile","glossary.html#receipt","glossary.html#transaction-type","glossary.html#fork-choice-rule","glossary.html#priority-gas-auction","glossary.html#sequencing","glossary.html#sequencer","glossary.html#sequencing-window","glossary.html#sequencing-epoch","glossary.html#l1-origin","glossary.html#deposits","glossary.html#deposited-transaction","glossary.html#l1-attributes-deposited-transaction","glossary.html#user-deposited-transaction","glossary.html#depositing-call","glossary.html#depositing-transaction","glossary.html#depositor","glossary.html#deposited-transaction-type","glossary.html#deposit-contract","glossary.html#withdrawals","glossary.html#relayer","glossary.html#finalization-period","glossary.html#batch-submission","glossary.html#data-availability","glossary.html#data-availability-provider","glossary.html#sequencer-batch","glossary.html#channel","glossary.html#channel-frame","glossary.html#batcher","glossary.html#batcher-transaction","glossary.html#batch-submission-frequency","glossary.html#channel-timeout","glossary.html#l2-output-root-proposals","glossary.html#proposer","glossary.html#l2-chain-derivation","glossary.html#l2-derivation-inputs","glossary.html#system-configuration","glossary.html#payload-attributes","glossary.html#l2-genesis-block","glossary.html#l2-chain-inception","glossary.html#safe-l2-block","glossary.html#safe-l2-head","glossary.html#unsafe-l2-block","glossary.html#unsafe-l2-head","glossary.html#unsafe-block-consolidation","glossary.html#finalized-l2-head","glossary.html#other-l2-chain-concepts","glossary.html#address-aliasing","glossary.html#rollup-node","glossary.html#rollup-driver","glossary.html#l1-attributes-predeployed-contract","glossary.html#l2-output-root","glossary.html#l2-output-oracle-contract","glossary.html#validator","glossary.html#fault-proof","glossary.html#time-slot","glossary.html#block-time","glossary.html#unsafe-sync","glossary.html#execution-engine-concepts","glossary.html#execution-engine"],"index":{"documentStore":{"docInfo":{"0":{"body":7,"breadcrumbs":4,"title":3},"1":{"body":51,"breadcrumbs":2,"title":1},"10":{"body":17,"breadcrumbs":3,"title":2},"100":{"body":260,"breadcrumbs":7,"title":1},"101":{"body":81,"breadcrumbs":7,"title":1},"102":{"body":7,"breadcrumbs":7,"title":1},"103":{"body":30,"breadcrumbs":7,"title":1},"104":{"body":9,"breadcrumbs":7,"title":1},"105":{"body":36,"breadcrumbs":7,"title":1},"106":{"body":72,"breadcrumbs":7,"title":1},"107":{"body":99,"breadcrumbs":7,"title":1},"108":{"body":53,"breadcrumbs":7,"title":1},"109":{"body":99,"breadcrumbs":9,"title":3},"11":{"body":33,"breadcrumbs":2,"title":1},"110":{"body":47,"breadcrumbs":9,"title":3},"111":{"body":97,"breadcrumbs":10,"title":4},"112":{"body":80,"breadcrumbs":10,"title":4},"113":{"body":31,"breadcrumbs":8,"title":2},"114":{"body":20,"breadcrumbs":9,"title":3},"115":{"body":26,"breadcrumbs":7,"title":1},"116":{"body":26,"breadcrumbs":7,"title":1},"117":{"body":85,"breadcrumbs":7,"title":1},"118":{"body":13,"breadcrumbs":10,"title":4},"119":{"body":112,"breadcrumbs":7,"title":1},"12":{"body":30,"breadcrumbs":2,"title":1},"120":{"body":57,"breadcrumbs":9,"title":3},"121":{"body":61,"breadcrumbs":9,"title":3},"122":{"body":60,"breadcrumbs":13,"title":4},"123":{"body":143,"breadcrumbs":10,"title":1},"124":{"body":0,"breadcrumbs":11,"title":2},"125":{"body":69,"breadcrumbs":10,"title":1},"126":{"body":149,"breadcrumbs":10,"title":1},"127":{"body":576,"breadcrumbs":10,"title":1},"128":{"body":9,"breadcrumbs":11,"title":2},"129":{"body":5,"breadcrumbs":10,"title":1},"13":{"body":29,"breadcrumbs":2,"title":1},"130":{"body":4,"breadcrumbs":10,"title":1},"131":{"body":4,"breadcrumbs":10,"title":1},"132":{"body":71,"breadcrumbs":11,"title":2},"133":{"body":42,"breadcrumbs":11,"title":2},"134":{"body":233,"breadcrumbs":11,"title":2},"135":{"body":167,"breadcrumbs":11,"title":2},"136":{"body":255,"breadcrumbs":10,"title":1},"137":{"body":130,"breadcrumbs":11,"title":4},"138":{"body":420,"breadcrumbs":8,"title":1},"139":{"body":59,"breadcrumbs":10,"title":3},"14":{"body":84,"breadcrumbs":3,"title":2},"140":{"body":49,"breadcrumbs":9,"title":2},"141":{"body":0,"breadcrumbs":9,"title":2},"142":{"body":147,"breadcrumbs":11,"title":4},"143":{"body":478,"breadcrumbs":11,"title":4},"144":{"body":64,"breadcrumbs":10,"title":3},"145":{"body":115,"breadcrumbs":9,"title":2},"146":{"body":133,"breadcrumbs":9,"title":2},"147":{"body":120,"breadcrumbs":9,"title":2},"148":{"body":33,"breadcrumbs":8,"title":1},"149":{"body":143,"breadcrumbs":11,"title":4},"15":{"body":18,"breadcrumbs":2,"title":1},"150":{"body":47,"breadcrumbs":9,"title":2},"151":{"body":68,"breadcrumbs":9,"title":2},"152":{"body":20,"breadcrumbs":9,"title":2},"153":{"body":311,"breadcrumbs":9,"title":2},"154":{"body":19,"breadcrumbs":11,"title":4},"155":{"body":480,"breadcrumbs":9,"title":2},"156":{"body":57,"breadcrumbs":10,"title":3},"157":{"body":874,"breadcrumbs":9,"title":2},"158":{"body":581,"breadcrumbs":9,"title":2},"159":{"body":43,"breadcrumbs":10,"title":3},"16":{"body":103,"breadcrumbs":2,"title":1},"160":{"body":140,"breadcrumbs":10,"title":3},"161":{"body":700,"breadcrumbs":11,"title":4},"162":{"body":65,"breadcrumbs":11,"title":4},"163":{"body":3,"breadcrumbs":8,"title":2},"164":{"body":116,"breadcrumbs":7,"title":1},"165":{"body":114,"breadcrumbs":7,"title":2},"166":{"body":77,"breadcrumbs":6,"title":1},"167":{"body":52,"breadcrumbs":8,"title":3},"168":{"body":548,"breadcrumbs":9,"title":4},"169":{"body":51,"breadcrumbs":6,"title":1},"17":{"body":62,"breadcrumbs":2,"title":1},"170":{"body":215,"breadcrumbs":6,"title":1},"171":{"body":128,"breadcrumbs":8,"title":3},"172":{"body":55,"breadcrumbs":8,"title":3},"173":{"body":146,"breadcrumbs":6,"title":1},"174":{"body":252,"breadcrumbs":7,"title":2},"175":{"body":142,"breadcrumbs":6,"title":1},"176":{"body":190,"breadcrumbs":9,"title":4},"177":{"body":55,"breadcrumbs":7,"title":2},"178":{"body":104,"breadcrumbs":8,"title":3},"179":{"body":88,"breadcrumbs":10,"title":5},"18":{"body":0,"breadcrumbs":4,"title":3},"180":{"body":30,"breadcrumbs":14,"title":5},"181":{"body":75,"breadcrumbs":10,"title":1},"182":{"body":116,"breadcrumbs":10,"title":1},"183":{"body":51,"breadcrumbs":11,"title":2},"184":{"body":59,"breadcrumbs":10,"title":1},"185":{"body":82,"breadcrumbs":10,"title":1},"186":{"body":63,"breadcrumbs":11,"title":2},"187":{"body":165,"breadcrumbs":10,"title":1},"188":{"body":126,"breadcrumbs":10,"title":1},"189":{"body":26,"breadcrumbs":11,"title":2},"19":{"body":93,"breadcrumbs":4,"title":3},"190":{"body":22,"breadcrumbs":11,"title":2},"191":{"body":162,"breadcrumbs":12,"title":3},"192":{"body":68,"breadcrumbs":10,"title":1},"193":{"body":0,"breadcrumbs":11,"title":2},"194":{"body":147,"breadcrumbs":11,"title":2},"195":{"body":121,"breadcrumbs":11,"title":2},"196":{"body":19,"breadcrumbs":11,"title":3},"197":{"body":8,"breadcrumbs":14,"title":3},"198":{"body":74,"breadcrumbs":12,"title":1},"199":{"body":179,"breadcrumbs":12,"title":1},"2":{"body":28,"breadcrumbs":3,"title":2},"20":{"body":141,"breadcrumbs":2,"title":1},"200":{"body":614,"breadcrumbs":13,"title":2},"201":{"body":348,"breadcrumbs":13,"title":2},"202":{"body":52,"breadcrumbs":14,"title":3},"203":{"body":79,"breadcrumbs":12,"title":1},"204":{"body":0,"breadcrumbs":12,"title":1},"205":{"body":44,"breadcrumbs":14,"title":3},"206":{"body":31,"breadcrumbs":12,"title":1},"207":{"body":25,"breadcrumbs":13,"title":2},"208":{"body":64,"breadcrumbs":12,"title":1},"209":{"body":78,"breadcrumbs":13,"title":2},"21":{"body":19,"breadcrumbs":3,"title":2},"210":{"body":29,"breadcrumbs":14,"title":3},"211":{"body":34,"breadcrumbs":12,"title":1},"212":{"body":80,"breadcrumbs":12,"title":1},"213":{"body":68,"breadcrumbs":13,"title":2},"214":{"body":112,"breadcrumbs":12,"title":1},"215":{"body":12,"breadcrumbs":12,"title":1},"216":{"body":15,"breadcrumbs":12,"title":1},"217":{"body":92,"breadcrumbs":13,"title":2},"218":{"body":22,"breadcrumbs":14,"title":3},"219":{"body":32,"breadcrumbs":12,"title":1},"22":{"body":72,"breadcrumbs":5,"title":2},"220":{"body":216,"breadcrumbs":12,"title":1},"221":{"body":110,"breadcrumbs":15,"title":4},"222":{"body":122,"breadcrumbs":12,"title":1},"223":{"body":123,"breadcrumbs":13,"title":2},"224":{"body":428,"breadcrumbs":13,"title":2},"225":{"body":58,"breadcrumbs":13,"title":2},"226":{"body":128,"breadcrumbs":13,"title":2},"227":{"body":229,"breadcrumbs":12,"title":1},"228":{"body":87,"breadcrumbs":12,"title":1},"229":{"body":12,"breadcrumbs":18,"title":5},"23":{"body":98,"breadcrumbs":6,"title":3},"230":{"body":90,"breadcrumbs":14,"title":1},"231":{"body":39,"breadcrumbs":14,"title":1},"232":{"body":93,"breadcrumbs":17,"title":4},"233":{"body":52,"breadcrumbs":14,"title":1},"234":{"body":65,"breadcrumbs":14,"title":1},"235":{"body":11,"breadcrumbs":14,"title":1},"236":{"body":64,"breadcrumbs":14,"title":1},"237":{"body":31,"breadcrumbs":15,"title":2},"238":{"body":65,"breadcrumbs":14,"title":1},"239":{"body":60,"breadcrumbs":14,"title":1},"24":{"body":0,"breadcrumbs":5,"title":2},"240":{"body":42,"breadcrumbs":15,"title":2},"241":{"body":53,"breadcrumbs":16,"title":3},"242":{"body":15,"breadcrumbs":17,"title":4},"243":{"body":27,"breadcrumbs":15,"title":2},"244":{"body":37,"breadcrumbs":16,"title":3},"245":{"body":90,"breadcrumbs":15,"title":2},"246":{"body":23,"breadcrumbs":16,"title":3},"247":{"body":31,"breadcrumbs":14,"title":1},"248":{"body":367,"breadcrumbs":14,"title":1},"249":{"body":54,"breadcrumbs":12,"title":2},"25":{"body":394,"breadcrumbs":7,"title":4},"250":{"body":27,"breadcrumbs":11,"title":1},"251":{"body":151,"breadcrumbs":12,"title":2},"252":{"body":0,"breadcrumbs":14,"title":4},"253":{"body":10,"breadcrumbs":12,"title":2},"254":{"body":39,"breadcrumbs":13,"title":3},"255":{"body":42,"breadcrumbs":12,"title":2},"256":{"body":96,"breadcrumbs":12,"title":2},"257":{"body":168,"breadcrumbs":12,"title":2},"258":{"body":122,"breadcrumbs":12,"title":2},"259":{"body":168,"breadcrumbs":12,"title":2},"26":{"body":251,"breadcrumbs":7,"title":4},"260":{"body":23,"breadcrumbs":12,"title":2},"261":{"body":43,"breadcrumbs":12,"title":2},"262":{"body":12,"breadcrumbs":12,"title":2},"263":{"body":43,"breadcrumbs":11,"title":1},"264":{"body":4,"breadcrumbs":5,"title":1},"265":{"body":61,"breadcrumbs":5,"title":1},"266":{"body":35,"breadcrumbs":5,"title":1},"267":{"body":24,"breadcrumbs":5,"title":1},"268":{"body":168,"breadcrumbs":5,"title":1},"269":{"body":71,"breadcrumbs":5,"title":1},"27":{"body":70,"breadcrumbs":6,"title":3},"270":{"body":33,"breadcrumbs":5,"title":1},"271":{"body":48,"breadcrumbs":5,"title":1},"272":{"body":41,"breadcrumbs":5,"title":1},"273":{"body":19,"breadcrumbs":5,"title":1},"274":{"body":59,"breadcrumbs":5,"title":1},"275":{"body":84,"breadcrumbs":5,"title":1},"276":{"body":30,"breadcrumbs":5,"title":1},"277":{"body":141,"breadcrumbs":5,"title":1},"278":{"body":16,"breadcrumbs":5,"title":1},"279":{"body":18,"breadcrumbs":5,"title":1},"28":{"body":142,"breadcrumbs":6,"title":3},"280":{"body":29,"breadcrumbs":5,"title":1},"281":{"body":43,"breadcrumbs":5,"title":1},"282":{"body":14,"breadcrumbs":5,"title":1},"283":{"body":25,"breadcrumbs":5,"title":1},"284":{"body":21,"breadcrumbs":5,"title":1},"285":{"body":13,"breadcrumbs":5,"title":1},"286":{"body":10,"breadcrumbs":5,"title":1},"287":{"body":18,"breadcrumbs":7,"title":3},"288":{"body":32,"breadcrumbs":5,"title":1},"289":{"body":96,"breadcrumbs":5,"title":1},"29":{"body":56,"breadcrumbs":5,"title":2},"290":{"body":18,"breadcrumbs":5,"title":1},"291":{"body":16,"breadcrumbs":5,"title":1},"292":{"body":8,"breadcrumbs":5,"title":1},"293":{"body":9,"breadcrumbs":5,"title":1},"294":{"body":51,"breadcrumbs":5,"title":1},"295":{"body":24,"breadcrumbs":5,"title":1},"296":{"body":127,"breadcrumbs":5,"title":1},"297":{"body":26,"breadcrumbs":5,"title":1},"298":{"body":87,"breadcrumbs":8,"title":4},"299":{"body":22,"breadcrumbs":5,"title":1},"3":{"body":17,"breadcrumbs":3,"title":2},"30":{"body":0,"breadcrumbs":6,"title":3},"300":{"body":12,"breadcrumbs":8,"title":4},"301":{"body":14,"breadcrumbs":8,"title":4},"302":{"body":12,"breadcrumbs":8,"title":4},"303":{"body":14,"breadcrumbs":8,"title":4},"304":{"body":13,"breadcrumbs":8,"title":2},"305":{"body":14,"breadcrumbs":7,"title":1},"306":{"body":25,"breadcrumbs":8,"title":2},"307":{"body":29,"breadcrumbs":9,"title":3},"308":{"body":70,"breadcrumbs":7,"title":1},"309":{"body":52,"breadcrumbs":8,"title":2},"31":{"body":69,"breadcrumbs":4,"title":1},"310":{"body":57,"breadcrumbs":7,"title":1},"311":{"body":123,"breadcrumbs":8,"title":2},"312":{"body":326,"breadcrumbs":9,"title":3},"313":{"body":36,"breadcrumbs":9,"title":3},"314":{"body":42,"breadcrumbs":8,"title":2},"315":{"body":88,"breadcrumbs":9,"title":3},"316":{"body":47,"breadcrumbs":9,"title":3},"317":{"body":58,"breadcrumbs":8,"title":2},"318":{"body":72,"breadcrumbs":12,"title":6},"319":{"body":100,"breadcrumbs":11,"title":5},"32":{"body":326,"breadcrumbs":5,"title":2},"320":{"body":130,"breadcrumbs":10,"title":4},"321":{"body":0,"breadcrumbs":10,"title":4},"322":{"body":49,"breadcrumbs":8,"title":2},"323":{"body":31,"breadcrumbs":7,"title":2},"324":{"body":19,"breadcrumbs":6,"title":1},"325":{"body":8,"breadcrumbs":10,"title":5},"326":{"body":43,"breadcrumbs":7,"title":2},"327":{"body":287,"breadcrumbs":6,"title":1},"328":{"body":51,"breadcrumbs":7,"title":2},"329":{"body":51,"breadcrumbs":7,"title":2},"33":{"body":139,"breadcrumbs":5,"title":2},"330":{"body":33,"breadcrumbs":8,"title":3},"331":{"body":219,"breadcrumbs":8,"title":3},"332":{"body":256,"breadcrumbs":7,"title":3},"333":{"body":0,"breadcrumbs":6,"title":2},"334":{"body":26,"breadcrumbs":7,"title":3},"335":{"body":22,"breadcrumbs":6,"title":2},"336":{"body":29,"breadcrumbs":6,"title":2},"337":{"body":41,"breadcrumbs":7,"title":3},"338":{"body":34,"breadcrumbs":7,"title":3},"339":{"body":31,"breadcrumbs":7,"title":3},"34":{"body":6,"breadcrumbs":6,"title":2},"340":{"body":25,"breadcrumbs":8,"title":4},"341":{"body":32,"breadcrumbs":8,"title":4},"342":{"body":26,"breadcrumbs":8,"title":4},"343":{"body":27,"breadcrumbs":7,"title":3},"344":{"body":27,"breadcrumbs":7,"title":3},"345":{"body":36,"breadcrumbs":9,"title":5},"346":{"body":28,"breadcrumbs":9,"title":5},"347":{"body":34,"breadcrumbs":8,"title":4},"348":{"body":30,"breadcrumbs":8,"title":4},"349":{"body":18,"breadcrumbs":9,"title":5},"35":{"body":186,"breadcrumbs":5,"title":1},"350":{"body":20,"breadcrumbs":6,"title":2},"351":{"body":31,"breadcrumbs":6,"title":2},"352":{"body":29,"breadcrumbs":6,"title":2},"353":{"body":24,"breadcrumbs":7,"title":3},"354":{"body":26,"breadcrumbs":6,"title":2},"355":{"body":48,"breadcrumbs":7,"title":3},"356":{"body":19,"breadcrumbs":6,"title":2},"357":{"body":35,"breadcrumbs":6,"title":2},"358":{"body":23,"breadcrumbs":6,"title":2},"359":{"body":18,"breadcrumbs":6,"title":2},"36":{"body":24,"breadcrumbs":6,"title":2},"360":{"body":0,"breadcrumbs":6,"title":2},"361":{"body":34,"breadcrumbs":7,"title":3},"362":{"body":48,"breadcrumbs":7,"title":3},"363":{"body":39,"breadcrumbs":6,"title":2},"364":{"body":0,"breadcrumbs":6,"title":2},"365":{"body":52,"breadcrumbs":7,"title":3},"366":{"body":20,"breadcrumbs":7,"title":3},"367":{"body":31,"breadcrumbs":7,"title":3},"368":{"body":37,"breadcrumbs":7,"title":3},"369":{"body":83,"breadcrumbs":7,"title":3},"37":{"body":8,"breadcrumbs":5,"title":1},"370":{"body":0,"breadcrumbs":6,"title":2},"371":{"body":15,"breadcrumbs":7,"title":3},"372":{"body":33,"breadcrumbs":6,"title":2},"373":{"body":37,"breadcrumbs":6,"title":2},"374":{"body":39,"breadcrumbs":6,"title":2},"375":{"body":28,"breadcrumbs":9,"title":5},"376":{"body":128,"breadcrumbs":8,"title":3},"377":{"body":6,"breadcrumbs":7,"title":2},"378":{"body":178,"breadcrumbs":8,"title":3},"379":{"body":58,"breadcrumbs":10,"title":5},"38":{"body":17,"breadcrumbs":8,"title":3},"380":{"body":52,"breadcrumbs":10,"title":5},"381":{"body":94,"breadcrumbs":7,"title":2},"382":{"body":52,"breadcrumbs":7,"title":2},"383":{"body":51,"breadcrumbs":9,"title":4},"384":{"body":23,"breadcrumbs":6,"title":1},"385":{"body":126,"breadcrumbs":8,"title":3},"386":{"body":29,"breadcrumbs":11,"title":6},"387":{"body":0,"breadcrumbs":7,"title":2},"388":{"body":22,"breadcrumbs":10,"title":5},"389":{"body":62,"breadcrumbs":9,"title":4},"39":{"body":186,"breadcrumbs":6,"title":1},"390":{"body":76,"breadcrumbs":9,"title":4},"391":{"body":14,"breadcrumbs":13,"title":4},"392":{"body":20,"breadcrumbs":10,"title":1},"393":{"body":7,"breadcrumbs":12,"title":3},"394":{"body":82,"breadcrumbs":12,"title":3},"395":{"body":177,"breadcrumbs":11,"title":2},"396":{"body":134,"breadcrumbs":12,"title":3},"397":{"body":3,"breadcrumbs":7,"title":1},"398":{"body":158,"breadcrumbs":7,"title":1},"399":{"body":40,"breadcrumbs":7,"title":1},"4":{"body":29,"breadcrumbs":2,"title":1},"40":{"body":75,"breadcrumbs":7,"title":2},"400":{"body":51,"breadcrumbs":8,"title":2},"401":{"body":3,"breadcrumbs":8,"title":2},"402":{"body":16,"breadcrumbs":7,"title":1},"403":{"body":9,"breadcrumbs":8,"title":2},"404":{"body":70,"breadcrumbs":10,"title":2},"405":{"body":150,"breadcrumbs":9,"title":1},"406":{"body":314,"breadcrumbs":11,"title":3},"407":{"body":38,"breadcrumbs":12,"title":4},"408":{"body":74,"breadcrumbs":12,"title":4},"409":{"body":41,"breadcrumbs":12,"title":4},"41":{"body":13,"breadcrumbs":6,"title":1},"410":{"body":0,"breadcrumbs":10,"title":2},"411":{"body":27,"breadcrumbs":13,"title":5},"412":{"body":19,"breadcrumbs":12,"title":4},"413":{"body":20,"breadcrumbs":13,"title":5},"414":{"body":24,"breadcrumbs":13,"title":5},"415":{"body":44,"breadcrumbs":13,"title":5},"416":{"body":64,"breadcrumbs":13,"title":5},"417":{"body":32,"breadcrumbs":14,"title":6},"418":{"body":75,"breadcrumbs":11,"title":3},"419":{"body":142,"breadcrumbs":12,"title":4},"42":{"body":36,"breadcrumbs":7,"title":2},"420":{"body":0,"breadcrumbs":9,"title":1},"421":{"body":18,"breadcrumbs":12,"title":4},"422":{"body":482,"breadcrumbs":10,"title":2},"423":{"body":101,"breadcrumbs":9,"title":1},"424":{"body":18,"breadcrumbs":9,"title":3},"425":{"body":80,"breadcrumbs":8,"title":2},"426":{"body":30,"breadcrumbs":8,"title":2},"427":{"body":7,"breadcrumbs":8,"title":1},"428":{"body":110,"breadcrumbs":10,"title":3},"429":{"body":279,"breadcrumbs":9,"title":2},"43":{"body":6,"breadcrumbs":8,"title":3},"430":{"body":10,"breadcrumbs":11,"title":3},"431":{"body":203,"breadcrumbs":9,"title":1},"432":{"body":116,"breadcrumbs":12,"title":4},"433":{"body":111,"breadcrumbs":11,"title":3},"434":{"body":6,"breadcrumbs":9,"title":3},"435":{"body":22,"breadcrumbs":8,"title":2},"436":{"body":16,"breadcrumbs":8,"title":2},"437":{"body":27,"breadcrumbs":11,"title":3},"438":{"body":0,"breadcrumbs":9,"title":1},"439":{"body":266,"breadcrumbs":14,"title":6},"44":{"body":8,"breadcrumbs":8,"title":3},"440":{"body":24,"breadcrumbs":12,"title":4},"441":{"body":35,"breadcrumbs":12,"title":5},"442":{"body":35,"breadcrumbs":10,"title":3},"443":{"body":51,"breadcrumbs":9,"title":2},"444":{"body":34,"breadcrumbs":11,"title":4},"445":{"body":53,"breadcrumbs":8,"title":1},"446":{"body":66,"breadcrumbs":9,"title":2},"447":{"body":57,"breadcrumbs":10,"title":3},"448":{"body":110,"breadcrumbs":8,"title":1},"449":{"body":115,"breadcrumbs":9,"title":2},"45":{"body":45,"breadcrumbs":8,"title":3},"450":{"body":75,"breadcrumbs":10,"title":3},"451":{"body":43,"breadcrumbs":11,"title":4},"452":{"body":106,"breadcrumbs":9,"title":2},"453":{"body":75,"breadcrumbs":10,"title":3},"454":{"body":66,"breadcrumbs":10,"title":3},"455":{"body":7,"breadcrumbs":8,"title":1},"456":{"body":130,"breadcrumbs":8,"title":1},"457":{"body":91,"breadcrumbs":11,"title":4},"458":{"body":6,"breadcrumbs":9,"title":3},"459":{"body":5,"breadcrumbs":8,"title":2},"46":{"body":64,"breadcrumbs":6,"title":1},"460":{"body":4,"breadcrumbs":8,"title":2},"461":{"body":8,"breadcrumbs":11,"title":3},"462":{"body":0,"breadcrumbs":10,"title":2},"463":{"body":25,"breadcrumbs":12,"title":4},"464":{"body":8,"breadcrumbs":12,"title":5},"465":{"body":20,"breadcrumbs":10,"title":3},"466":{"body":18,"breadcrumbs":10,"title":3},"467":{"body":12,"breadcrumbs":9,"title":3},"468":{"body":4,"breadcrumbs":8,"title":2},"469":{"body":2,"breadcrumbs":8,"title":2},"47":{"body":40,"breadcrumbs":6,"title":1},"470":{"body":2,"breadcrumbs":8,"title":2},"471":{"body":52,"breadcrumbs":12,"title":5},"472":{"body":0,"breadcrumbs":9,"title":2},"473":{"body":114,"breadcrumbs":8,"title":1},"474":{"body":174,"breadcrumbs":9,"title":2},"475":{"body":13,"breadcrumbs":9,"title":2},"476":{"body":32,"breadcrumbs":8,"title":1},"477":{"body":6,"breadcrumbs":8,"title":1},"478":{"body":77,"breadcrumbs":10,"title":3},"479":{"body":167,"breadcrumbs":9,"title":2},"48":{"body":205,"breadcrumbs":8,"title":3},"480":{"body":83,"breadcrumbs":9,"title":2},"481":{"body":39,"breadcrumbs":10,"title":3},"482":{"body":40,"breadcrumbs":9,"title":2},"483":{"body":72,"breadcrumbs":9,"title":2},"484":{"body":102,"breadcrumbs":8,"title":1},"485":{"body":0,"breadcrumbs":8,"title":1},"486":{"body":65,"breadcrumbs":11,"title":4},"487":{"body":59,"breadcrumbs":11,"title":4},"488":{"body":38,"breadcrumbs":10,"title":3},"489":{"body":54,"breadcrumbs":10,"title":3},"49":{"body":114,"breadcrumbs":8,"title":3},"490":{"body":70,"breadcrumbs":10,"title":3},"491":{"body":0,"breadcrumbs":10,"title":3},"492":{"body":85,"breadcrumbs":8,"title":1},"493":{"body":186,"breadcrumbs":9,"title":2},"494":{"body":180,"breadcrumbs":9,"title":2},"495":{"body":34,"breadcrumbs":11,"title":3},"496":{"body":15,"breadcrumbs":10,"title":2},"497":{"body":30,"breadcrumbs":12,"title":4},"498":{"body":40,"breadcrumbs":11,"title":3},"499":{"body":155,"breadcrumbs":11,"title":3},"5":{"body":40,"breadcrumbs":2,"title":1},"50":{"body":57,"breadcrumbs":8,"title":3},"500":{"body":33,"breadcrumbs":10,"title":2},"501":{"body":16,"breadcrumbs":10,"title":2},"502":{"body":45,"breadcrumbs":9,"title":1},"503":{"body":31,"breadcrumbs":9,"title":1},"504":{"body":13,"breadcrumbs":10,"title":2},"505":{"body":23,"breadcrumbs":11,"title":3},"506":{"body":6,"breadcrumbs":9,"title":1},"507":{"body":53,"breadcrumbs":9,"title":1},"508":{"body":53,"breadcrumbs":8,"title":1},"509":{"body":89,"breadcrumbs":8,"title":1},"51":{"body":24,"breadcrumbs":9,"title":4},"510":{"body":65,"breadcrumbs":8,"title":1},"511":{"body":149,"breadcrumbs":8,"title":1},"512":{"body":37,"breadcrumbs":8,"title":1},"513":{"body":11,"breadcrumbs":8,"title":1},"514":{"body":11,"breadcrumbs":8,"title":1},"515":{"body":11,"breadcrumbs":8,"title":1},"516":{"body":11,"breadcrumbs":8,"title":1},"517":{"body":0,"breadcrumbs":9,"title":2},"518":{"body":9,"breadcrumbs":8,"title":1},"519":{"body":28,"breadcrumbs":8,"title":1},"52":{"body":370,"breadcrumbs":6,"title":1},"520":{"body":7,"breadcrumbs":8,"title":1},"521":{"body":0,"breadcrumbs":8,"title":1},"522":{"body":58,"breadcrumbs":8,"title":1},"523":{"body":0,"breadcrumbs":8,"title":1},"524":{"body":56,"breadcrumbs":8,"title":1},"525":{"body":28,"breadcrumbs":8,"title":1},"526":{"body":15,"breadcrumbs":11,"title":4},"527":{"body":84,"breadcrumbs":8,"title":1},"528":{"body":7,"breadcrumbs":8,"title":1},"529":{"body":53,"breadcrumbs":8,"title":1},"53":{"body":146,"breadcrumbs":7,"title":2},"530":{"body":15,"breadcrumbs":5,"title":2},"531":{"body":49,"breadcrumbs":4,"title":1},"532":{"body":26,"breadcrumbs":5,"title":2},"533":{"body":25,"breadcrumbs":5,"title":2},"534":{"body":94,"breadcrumbs":5,"title":2},"535":{"body":37,"breadcrumbs":4,"title":1},"536":{"body":73,"breadcrumbs":7,"title":3},"537":{"body":83,"breadcrumbs":5,"title":1},"538":{"body":50,"breadcrumbs":5,"title":1},"539":{"body":77,"breadcrumbs":8,"title":4},"54":{"body":70,"breadcrumbs":9,"title":4},"540":{"body":50,"breadcrumbs":6,"title":2},"541":{"body":146,"breadcrumbs":8,"title":4},"542":{"body":0,"breadcrumbs":6,"title":2},"543":{"body":80,"breadcrumbs":6,"title":2},"544":{"body":20,"breadcrumbs":7,"title":3},"545":{"body":188,"breadcrumbs":5,"title":1},"546":{"body":65,"breadcrumbs":5,"title":1},"547":{"body":90,"breadcrumbs":5,"title":1},"548":{"body":85,"breadcrumbs":5,"title":1},"549":{"body":54,"breadcrumbs":5,"title":1},"55":{"body":25,"breadcrumbs":10,"title":5},"550":{"body":23,"breadcrumbs":5,"title":1},"551":{"body":39,"breadcrumbs":6,"title":2},"552":{"body":72,"breadcrumbs":7,"title":3},"553":{"body":86,"breadcrumbs":8,"title":4},"554":{"body":26,"breadcrumbs":5,"title":1},"555":{"body":146,"breadcrumbs":5,"title":1},"556":{"body":12,"breadcrumbs":6,"title":2},"557":{"body":12,"breadcrumbs":6,"title":2},"558":{"body":12,"breadcrumbs":6,"title":2},"559":{"body":12,"breadcrumbs":7,"title":3},"56":{"body":17,"breadcrumbs":8,"title":3},"560":{"body":12,"breadcrumbs":7,"title":3},"561":{"body":12,"breadcrumbs":7,"title":3},"562":{"body":17,"breadcrumbs":6,"title":2},"563":{"body":16,"breadcrumbs":6,"title":2},"564":{"body":47,"breadcrumbs":5,"title":1},"565":{"body":0,"breadcrumbs":6,"title":2},"566":{"body":25,"breadcrumbs":7,"title":3},"567":{"body":37,"breadcrumbs":6,"title":2},"568":{"body":17,"breadcrumbs":6,"title":2},"569":{"body":48,"breadcrumbs":6,"title":3},"57":{"body":19,"breadcrumbs":9,"title":4},"570":{"body":73,"breadcrumbs":4,"title":1},"571":{"body":194,"breadcrumbs":6,"title":3},"572":{"body":113,"breadcrumbs":5,"title":2},"573":{"body":0,"breadcrumbs":7,"title":4},"574":{"body":356,"breadcrumbs":4,"title":1},"575":{"body":393,"breadcrumbs":4,"title":1},"576":{"body":21,"breadcrumbs":5,"title":2},"577":{"body":7,"breadcrumbs":6,"title":3},"578":{"body":9,"breadcrumbs":8,"title":5},"579":{"body":125,"breadcrumbs":5,"title":2},"58":{"body":134,"breadcrumbs":9,"title":4},"580":{"body":63,"breadcrumbs":5,"title":2},"581":{"body":165,"breadcrumbs":3,"title":1},"582":{"body":78,"breadcrumbs":3,"title":1},"583":{"body":142,"breadcrumbs":6,"title":2},"584":{"body":69,"breadcrumbs":6,"title":2},"585":{"body":45,"breadcrumbs":7,"title":3},"586":{"body":0,"breadcrumbs":6,"title":2},"587":{"body":46,"breadcrumbs":9,"title":5},"588":{"body":50,"breadcrumbs":4,"title":1},"589":{"body":6,"breadcrumbs":4,"title":1},"59":{"body":92,"breadcrumbs":8,"title":3},"590":{"body":37,"breadcrumbs":5,"title":2},"591":{"body":121,"breadcrumbs":5,"title":2},"592":{"body":0,"breadcrumbs":5,"title":2},"593":{"body":43,"breadcrumbs":5,"title":2},"594":{"body":77,"breadcrumbs":5,"title":2},"595":{"body":41,"breadcrumbs":5,"title":2},"596":{"body":30,"breadcrumbs":5,"title":2},"597":{"body":21,"breadcrumbs":5,"title":2},"598":{"body":59,"breadcrumbs":6,"title":3},"599":{"body":25,"breadcrumbs":5,"title":2},"6":{"body":0,"breadcrumbs":2,"title":1},"60":{"body":121,"breadcrumbs":7,"title":2},"600":{"body":84,"breadcrumbs":5,"title":2},"601":{"body":28,"breadcrumbs":7,"title":4},"602":{"body":64,"breadcrumbs":7,"title":4},"603":{"body":15,"breadcrumbs":5,"title":2},"604":{"body":62,"breadcrumbs":5,"title":2},"605":{"body":67,"breadcrumbs":5,"title":2},"606":{"body":0,"breadcrumbs":5,"title":2},"607":{"body":27,"breadcrumbs":5,"title":2},"608":{"body":20,"breadcrumbs":5,"title":2},"609":{"body":118,"breadcrumbs":4,"title":1},"61":{"body":35,"breadcrumbs":6,"title":1},"610":{"body":25,"breadcrumbs":4,"title":1},"611":{"body":141,"breadcrumbs":4,"title":1},"612":{"body":67,"breadcrumbs":6,"title":3},"613":{"body":50,"breadcrumbs":5,"title":2},"614":{"body":175,"breadcrumbs":5,"title":2},"615":{"body":31,"breadcrumbs":5,"title":2},"616":{"body":11,"breadcrumbs":5,"title":2},"617":{"body":45,"breadcrumbs":4,"title":1},"618":{"body":9,"breadcrumbs":5,"title":2},"619":{"body":21,"breadcrumbs":5,"title":2},"62":{"body":132,"breadcrumbs":6,"title":1},"620":{"body":20,"breadcrumbs":5,"title":2},"621":{"body":17,"breadcrumbs":5,"title":2},"622":{"body":26,"breadcrumbs":9,"title":6},"623":{"body":464,"breadcrumbs":4,"title":1},"624":{"body":4,"breadcrumbs":4,"title":1},"625":{"body":31,"breadcrumbs":4,"title":1},"626":{"body":71,"breadcrumbs":4,"title":1},"627":{"body":85,"breadcrumbs":4,"title":1},"628":{"body":25,"breadcrumbs":4,"title":1},"629":{"body":49,"breadcrumbs":5,"title":2},"63":{"body":8,"breadcrumbs":7,"title":2},"630":{"body":4,"breadcrumbs":4,"title":1},"631":{"body":25,"breadcrumbs":4,"title":1},"632":{"body":6,"breadcrumbs":4,"title":1},"633":{"body":108,"breadcrumbs":5,"title":2},"634":{"body":113,"breadcrumbs":5,"title":2},"635":{"body":17,"breadcrumbs":5,"title":2},"636":{"body":34,"breadcrumbs":4,"title":1},"637":{"body":4,"breadcrumbs":4,"title":1},"638":{"body":34,"breadcrumbs":4,"title":1},"639":{"body":19,"breadcrumbs":4,"title":1},"64":{"body":17,"breadcrumbs":6,"title":1},"640":{"body":128,"breadcrumbs":4,"title":1},"641":{"body":34,"breadcrumbs":4,"title":1},"642":{"body":4,"breadcrumbs":4,"title":1},"643":{"body":110,"breadcrumbs":4,"title":1},"644":{"body":57,"breadcrumbs":4,"title":1},"645":{"body":53,"breadcrumbs":5,"title":2},"646":{"body":4,"breadcrumbs":4,"title":1},"647":{"body":19,"breadcrumbs":4,"title":1},"648":{"body":111,"breadcrumbs":4,"title":1},"649":{"body":40,"breadcrumbs":4,"title":1},"65":{"body":133,"breadcrumbs":6,"title":1},"650":{"body":83,"breadcrumbs":4,"title":1},"651":{"body":209,"breadcrumbs":4,"title":1},"652":{"body":1,"breadcrumbs":5,"title":2},"653":{"body":29,"breadcrumbs":4,"title":1},"654":{"body":39,"breadcrumbs":5,"title":2},"655":{"body":28,"breadcrumbs":5,"title":2},"656":{"body":21,"breadcrumbs":5,"title":2},"657":{"body":336,"breadcrumbs":5,"title":2},"658":{"body":25,"breadcrumbs":4,"title":1},"659":{"body":0,"breadcrumbs":5,"title":2},"66":{"body":81,"breadcrumbs":7,"title":2},"660":{"body":33,"breadcrumbs":7,"title":4},"661":{"body":31,"breadcrumbs":4,"title":1},"662":{"body":106,"breadcrumbs":5,"title":2},"663":{"body":78,"breadcrumbs":6,"title":3},"664":{"body":326,"breadcrumbs":4,"title":1},"665":{"body":26,"breadcrumbs":5,"title":2},"666":{"body":0,"breadcrumbs":5,"title":2},"667":{"body":113,"breadcrumbs":8,"title":5},"668":{"body":38,"breadcrumbs":5,"title":2},"669":{"body":58,"breadcrumbs":7,"title":2},"67":{"body":60,"breadcrumbs":8,"title":3},"670":{"body":1,"breadcrumbs":7,"title":2},"671":{"body":21,"breadcrumbs":6,"title":2},"672":{"body":36,"breadcrumbs":6,"title":2},"673":{"body":1,"breadcrumbs":6,"title":2},"674":{"body":102,"breadcrumbs":6,"title":3},"675":{"body":27,"breadcrumbs":5,"title":2},"676":{"body":36,"breadcrumbs":7,"title":4},"677":{"body":71,"breadcrumbs":6,"title":3},"678":{"body":1,"breadcrumbs":5,"title":2},"679":{"body":21,"breadcrumbs":6,"title":2},"68":{"body":54,"breadcrumbs":8,"title":3},"680":{"body":29,"breadcrumbs":5,"title":1},"681":{"body":0,"breadcrumbs":6,"title":2},"682":{"body":98,"breadcrumbs":5,"title":1},"683":{"body":54,"breadcrumbs":5,"title":1},"684":{"body":54,"breadcrumbs":5,"title":1},"685":{"body":83,"breadcrumbs":5,"title":1},"686":{"body":60,"breadcrumbs":5,"title":1},"687":{"body":0,"breadcrumbs":6,"title":2},"688":{"body":94,"breadcrumbs":7,"title":3},"689":{"body":156,"breadcrumbs":6,"title":2},"69":{"body":97,"breadcrumbs":8,"title":3},"690":{"body":58,"breadcrumbs":5,"title":2},"691":{"body":40,"breadcrumbs":5,"title":2},"692":{"body":53,"breadcrumbs":7,"title":4},"693":{"body":33,"breadcrumbs":6,"title":3},"694":{"body":8,"breadcrumbs":4,"title":1},"695":{"body":0,"breadcrumbs":4,"title":1},"696":{"body":105,"breadcrumbs":4,"title":1},"697":{"body":0,"breadcrumbs":4,"title":1},"698":{"body":136,"breadcrumbs":4,"title":1},"699":{"body":19,"breadcrumbs":4,"title":1},"7":{"body":47,"breadcrumbs":3,"title":2},"70":{"body":0,"breadcrumbs":7,"title":2},"700":{"body":0,"breadcrumbs":4,"title":1},"701":{"body":271,"breadcrumbs":5,"title":2},"702":{"body":0,"breadcrumbs":5,"title":2},"703":{"body":28,"breadcrumbs":5,"title":2},"704":{"body":76,"breadcrumbs":6,"title":2},"705":{"body":105,"breadcrumbs":6,"title":2},"706":{"body":70,"breadcrumbs":8,"title":4},"707":{"body":0,"breadcrumbs":6,"title":2},"708":{"body":43,"breadcrumbs":7,"title":3},"709":{"body":79,"breadcrumbs":7,"title":3},"71":{"body":79,"breadcrumbs":9,"title":4},"710":{"body":10,"breadcrumbs":5,"title":1},"711":{"body":10,"breadcrumbs":5,"title":1},"712":{"body":35,"breadcrumbs":5,"title":1},"713":{"body":106,"breadcrumbs":5,"title":1},"714":{"body":92,"breadcrumbs":6,"title":2},"715":{"body":0,"breadcrumbs":5,"title":1},"716":{"body":22,"breadcrumbs":7,"title":3},"717":{"body":98,"breadcrumbs":6,"title":2},"718":{"body":0,"breadcrumbs":6,"title":2},"719":{"body":92,"breadcrumbs":8,"title":4},"72":{"body":25,"breadcrumbs":11,"title":6},"720":{"body":30,"breadcrumbs":7,"title":3},"721":{"body":50,"breadcrumbs":7,"title":3},"722":{"body":22,"breadcrumbs":7,"title":3},"723":{"body":31,"breadcrumbs":7,"title":3},"724":{"body":15,"breadcrumbs":5,"title":2},"725":{"body":43,"breadcrumbs":4,"title":1},"726":{"body":147,"breadcrumbs":7,"title":4},"727":{"body":58,"breadcrumbs":5,"title":2},"728":{"body":27,"breadcrumbs":5,"title":2},"729":{"body":67,"breadcrumbs":5,"title":2},"73":{"body":63,"breadcrumbs":10,"title":5},"730":{"body":49,"breadcrumbs":4,"title":1},"731":{"body":161,"breadcrumbs":2,"title":1},"732":{"body":0,"breadcrumbs":3,"title":2},"733":{"body":9,"breadcrumbs":4,"title":3},"734":{"body":12,"breadcrumbs":4,"title":3},"735":{"body":62,"breadcrumbs":2,"title":1},"736":{"body":12,"breadcrumbs":2,"title":1},"737":{"body":34,"breadcrumbs":4,"title":3},"738":{"body":38,"breadcrumbs":4,"title":3},"739":{"body":13,"breadcrumbs":4,"title":3},"74":{"body":17,"breadcrumbs":11,"title":4},"740":{"body":27,"breadcrumbs":4,"title":3},"741":{"body":27,"breadcrumbs":4,"title":3},"742":{"body":45,"breadcrumbs":2,"title":1},"743":{"body":19,"breadcrumbs":3,"title":2},"744":{"body":34,"breadcrumbs":4,"title":3},"745":{"body":57,"breadcrumbs":4,"title":3},"746":{"body":33,"breadcrumbs":2,"title":1},"747":{"body":31,"breadcrumbs":2,"title":1},"748":{"body":50,"breadcrumbs":3,"title":2},"749":{"body":36,"breadcrumbs":3,"title":2},"75":{"body":122,"breadcrumbs":8,"title":1},"750":{"body":9,"breadcrumbs":3,"title":2},"751":{"body":80,"breadcrumbs":2,"title":1},"752":{"body":34,"breadcrumbs":3,"title":2},"753":{"body":41,"breadcrumbs":5,"title":4},"754":{"body":21,"breadcrumbs":4,"title":3},"755":{"body":20,"breadcrumbs":3,"title":2},"756":{"body":9,"breadcrumbs":3,"title":2},"757":{"body":15,"breadcrumbs":2,"title":1},"758":{"body":21,"breadcrumbs":4,"title":3},"759":{"body":46,"breadcrumbs":3,"title":2},"76":{"body":41,"breadcrumbs":9,"title":2},"760":{"body":53,"breadcrumbs":2,"title":1},"761":{"body":10,"breadcrumbs":2,"title":1},"762":{"body":30,"breadcrumbs":3,"title":2},"763":{"body":0,"breadcrumbs":3,"title":2},"764":{"body":48,"breadcrumbs":3,"title":2},"765":{"body":36,"breadcrumbs":4,"title":3},"766":{"body":54,"breadcrumbs":3,"title":2},"767":{"body":77,"breadcrumbs":2,"title":1},"768":{"body":22,"breadcrumbs":3,"title":2},"769":{"body":40,"breadcrumbs":2,"title":1},"77":{"body":18,"breadcrumbs":9,"title":2},"770":{"body":50,"breadcrumbs":3,"title":2},"771":{"body":105,"breadcrumbs":4,"title":3},"772":{"body":97,"breadcrumbs":3,"title":2},"773":{"body":0,"breadcrumbs":5,"title":4},"774":{"body":36,"breadcrumbs":2,"title":1},"775":{"body":20,"breadcrumbs":4,"title":3},"776":{"body":38,"breadcrumbs":4,"title":3},"777":{"body":29,"breadcrumbs":3,"title":2},"778":{"body":45,"breadcrumbs":3,"title":2},"779":{"body":121,"breadcrumbs":4,"title":3},"78":{"body":294,"breadcrumbs":10,"title":3},"780":{"body":21,"breadcrumbs":4,"title":3},"781":{"body":18,"breadcrumbs":4,"title":3},"782":{"body":10,"breadcrumbs":4,"title":3},"783":{"body":25,"breadcrumbs":4,"title":3},"784":{"body":10,"breadcrumbs":4,"title":3},"785":{"body":49,"breadcrumbs":4,"title":3},"786":{"body":21,"breadcrumbs":4,"title":3},"787":{"body":0,"breadcrumbs":4,"title":3},"788":{"body":17,"breadcrumbs":3,"title":2},"789":{"body":91,"breadcrumbs":3,"title":2},"79":{"body":79,"breadcrumbs":11,"title":4},"790":{"body":26,"breadcrumbs":3,"title":2},"791":{"body":22,"breadcrumbs":5,"title":4},"792":{"body":14,"breadcrumbs":4,"title":3},"793":{"body":7,"breadcrumbs":5,"title":4},"794":{"body":46,"breadcrumbs":2,"title":1},"795":{"body":14,"breadcrumbs":3,"title":2},"796":{"body":32,"breadcrumbs":3,"title":2},"797":{"body":36,"breadcrumbs":3,"title":2},"798":{"body":21,"breadcrumbs":3,"title":2},"799":{"body":0,"breadcrumbs":4,"title":3},"8":{"body":51,"breadcrumbs":3,"title":2},"80":{"body":79,"breadcrumbs":10,"title":3},"800":{"body":71,"breadcrumbs":3,"title":2},"81":{"body":23,"breadcrumbs":10,"title":5},"82":{"body":74,"breadcrumbs":6,"title":1},"83":{"body":36,"breadcrumbs":9,"title":4},"84":{"body":112,"breadcrumbs":7,"title":2},"85":{"body":128,"breadcrumbs":9,"title":4},"86":{"body":153,"breadcrumbs":10,"title":5},"87":{"body":17,"breadcrumbs":6,"title":1},"88":{"body":0,"breadcrumbs":7,"title":2},"89":{"body":36,"breadcrumbs":7,"title":2},"9":{"body":27,"breadcrumbs":3,"title":2},"90":{"body":81,"breadcrumbs":9,"title":3},"91":{"body":29,"breadcrumbs":8,"title":2},"92":{"body":34,"breadcrumbs":9,"title":3},"93":{"body":54,"breadcrumbs":9,"title":3},"94":{"body":16,"breadcrumbs":7,"title":1},"95":{"body":56,"breadcrumbs":8,"title":2},"96":{"body":22,"breadcrumbs":11,"title":5},"97":{"body":19,"breadcrumbs":11,"title":5},"98":{"body":419,"breadcrumbs":12,"title":6},"99":{"body":0,"breadcrumbs":8,"title":2}},"docs":{"0":{"body":"Table of Contents About Optimism About the OP Stack Site Navigation","breadcrumbs":"Introduction » OP Stack Specification","id":"0","title":"OP Stack Specification"},"1":{"body":"Optimism is a project dedicated to scaling Ethereum's technology and expanding its ability to coordinate people from across the world to build effective decentralized economies and governance systems. The Optimism Collective builds open-source software that powers scalable blockchains and aims to address key governance and economic challenges in the wider Ethereum ecosystem. Optimism operates on the principle of impact=profit , the idea that individuals who positively impact the Collective should be proportionally rewarded with profit. Change the incentives and you change the world.","breadcrumbs":"Introduction » About Optimism","id":"1","title":"About Optimism"},"10":{"body":"We strive to preserve three critical properties: liveness, validity, and availability. A protocol that can maintain these properties can, effectively, scale Ethereum without sacrificing security.","breadcrumbs":"Background » Protocol Guarantees","id":"10","title":"Protocol Guarantees"},"100":{"body":"This updates which L2 blocks the engine considers to be canonical (forkchoiceState argument), and optionally initiates block production (payloadAttributes argument). Within the rollup, the types of forkchoice updates translate as: headBlockHash: block hash of the head of the canonical chain. Labeled \"unsafe\" in user JSON-RPC. Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts. safeBlockHash: block hash of the canonical chain, derived from L1 data, unlikely to reorg. finalizedBlockHash: irreversible block hash, matches lower boundary of the dispute period. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV2 : the extended PayloadAttributesV2 Extended PayloadAttributesV2 PayloadAttributesV2 is extended to: PayloadAttributesV2: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The type notation used here refers to the HEX value encoding used by the Ethereum JSON-RPC API specification , as this structure will need to be sent over JSON-RPC. array refers to a JSON array. Each item of the transactions array is a byte list encoding a transaction: TransactionType || TransactionPayload or LegacyTransaction, as defined in EIP-2718 . This is equivalent to the transactions field in ExecutionPayloadV2 The transactions field is optional: If empty or missing: no changes to engine behavior. The sequencers will (if enabled) build a block by consuming transactions from the transaction pool. If present and non-empty: the payload MUST be produced starting with this exact list of transactions. The rollup driver determines the transaction list based on deterministic L1 inputs. The noTxPool is optional as well, and extends the transactions meaning: If false, the execution engine is free to pack additional transactions from external sources like the tx pool into the payload, after any of the transactions. This is the default behavior a L1 node implements. If true, the execution engine must not change anything about the given list of transactions. If the transactions field is present, the engine must execute the transactions in order and return STATUS_INVALID if there is an error processing the transactions. It must return STATUS_VALID if all of the transactions could be executed without error. Note : The state transition rules have been modified such that deposits will never fail so if engine_forkchoiceUpdatedV2 returns STATUS_INVALID it is because a batched transaction is invalid. The gasLimit is optional w.r.t. compatibility with L1, but required when used as rollup. This field overrides the gas limit used during block-building. If not specified as rollup, a STATUS_INVALID is returned.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV2","id":"100","title":"engine_forkchoiceUpdatedV2"},"101":{"body":"See engine_forkchoiceUpdatedV2 for a description of the forkchoice updated method. engine_forkchoiceUpdatedV3 must only be called with Ecotone payload. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV3 : the extended PayloadAttributesV3 Extended PayloadAttributesV3 PayloadAttributesV3 is extended to: PayloadAttributesV3: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 parentBeaconBlockRoot: DATA (32 bytes) transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The requirements of this object are the same as extended PayloadAttributesV2 with the addition of parentBeaconBlockRoot which is the parent beacon block root from the L1 origin block of the L2 block. Starting at Ecotone, the parentBeaconBlockRoot must be set to the L1 origin parentBeaconBlockRoot, or a zero bytes32 if the Dencun functionality with parentBeaconBlockRoot is not active on L1.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV3","id":"101","title":"engine_forkchoiceUpdatedV3"},"102":{"body":"No modifications to engine_newPayloadV2 . Applies a L2 block to the engine state.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV2","id":"102","title":"engine_newPayloadV2"},"103":{"body":"engine_newPayloadV3 applies an Ecotone L2 block to the engine state. There are no modifications to this API. engine_newPayloadV3 must only be called with Ecotone payload. The additional parameters should be set as follows: expectedBlobVersionedHashes MUST be an empty array. parentBeaconBlockRoot MUST be the parent beacon block root from the L1 origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV3","id":"103","title":"engine_newPayloadV3"},"104":{"body":"No modifications to engine_getPayloadV2 . Retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV2 when called with payloadAttributes.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV2","id":"104","title":"engine_getPayloadV2"},"105":{"body":"engine_getPayloadV3 retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV3 when called with payloadAttributes. engine_getPayloadV3 must only be called with Ecotone payload. Extended Response The response is extended to: { executionPayload: ExecutionPayload blockValue: QUANTITY blobsBundle: BlobsBundle shouldOverrideBuilder: BOOLEAN parentBeaconBlockRoot: DATA (32 bytes)\n} In Ecotone it MUST be set to the parentBeaconBlockRoot from the L1 Origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV3","id":"105","title":"engine_getPayloadV3"},"106":{"body":"Optional extension to the Engine API. Signals superchain information to the Engine: V1 signals which protocol version is recommended and required. Types: SuperchainSignal: { recommended: ProtocolVersion; required: ProtocolVersion;\n} ProtocolVersion: encoded for RPC as defined in Protocol Version format specification . Parameters: signal: SuperchainSignal, the signaled superchain information. Returns: ProtocolVersion: the latest supported OP-Stack protocol version of the execution engine. The execution engine SHOULD warn the user when the recommended version is newer than the current version supported by the execution engine. The execution engine SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the execution engine operator.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_signalSuperchainV1","id":"106","title":"engine_signalSuperchainV1"},"107":{"body":"The execution engine can acquire all data through the rollup node, as derived from L1: P2P networking is strictly optional. However, to not bottleneck on L1 data retrieval speed, the P2P network functionality SHOULD be enabled, serving: Peer discovery ( Disc v5 ) eth/66 : Transaction pool (consumed by sequencer nodes) State sync (happy-path for fast trustless db replication) Historical block header and body retrieval New blocks are acquired through the consensus layer instead (rollup node) No modifications to L1 network functionality are required, except configuration: networkID : Distinguishes the L2 network from L1 and testnets. Equal to the chainID of the rollup network. Activate Merge fork: Enables Engine API and disables propagation of blocks, as block headers cannot be authenticated without consensus layer. Bootnode list: DiscV5 is a shared network, bootstrap is faster through connecting with L2 nodes first.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Networking","id":"107","title":"Networking"},"108":{"body":"The execution engine can operate sync in different ways: Happy-path: rollup node informs engine of the desired chain head as determined by L1, completes through engine P2P. Worst-case: rollup node detects stalled engine, completes sync purely from L1 data, no peers required. The happy-path is more suitable to bring new nodes online quickly, as the engine implementation can sync state faster through methods like snap-sync .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Sync","id":"108","title":"Sync"},"109":{"body":"The rollup node informs the engine of the L2 chain head, unconditionally (part of regular node operation): Bedrock / Canyon / Delta Payloads engine_newPayloadV2 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV2 is called with the current unsafe/safe/finalized L2 block hashes. Ecotone Payloads engine_newPayloadV3 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV3 is called with the current unsafe/safe/finalized L2 block hashes. The engine requests headers from peers, in reverse till the parent hash matches the local chain The engine catches up: a) A form of state sync is activated towards the finalized or head block hash b) A form of block sync pulls block bodies and processes towards head block hash The exact P2P based sync is out of scope for the L2 specification: the operation within the engine is the exact same as with L1 (although with an EVM that supports deposits).","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Happy-path sync","id":"109","title":"Happy-path sync"},"11":{"body":"Liveness is defined as the ability for any party to be able to extend the rollup chain by including a transaction within a bounded amount of time. It should not be possible for an actor to block the inclusion of any given transaction for more than this bounded time period. This bounded time period should also be acceptable such that inclusion is not just theoretically possible but practically useful.","breadcrumbs":"Background » Liveness","id":"11","title":"Liveness"},"110":{"body":"Engine is out of sync, not peered and/or stalled due other reasons. The rollup node maintains latest head from engine (poll eth_getBlockByNumber and/or maintain a header subscription) The rollup node activates sync if the engine is out of sync but not syncing through P2P (eth_syncing) The rollup node inserts blocks, derived from L1, one by one, potentially adapting to L1 reorg(s), as outlined in the rollup node spec .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Worst-case sync","id":"110","title":"Worst-case sync"},"111":{"body":"EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction, plus a list of \"blobs\": \"Binary Large Object\", i.e. a dedicated data type for serving Data-Availability as base-layer. With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception: as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type. EIP-4844 is disabled as following: Transaction network-layer announcements, announcing blob-type transactions, are ignored. Transactions of the blob-type, through the RPC or otherwise, are not allowed into the transaction pool. Block-building code does not select EIP-4844 transactions. An L2 block state-transition with EIP-4844 transactions is invalid. The BLOBBASEFEE opcode is present but its semantics are altered because there are no blobs processed by L2. The opcode will always push a value of 1 onto the stack.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: disable Blob-transactions","id":"111","title":"Ecotone: disable Blob-transactions"},"112":{"body":"EIP-4788 introduces a \"beacon block root\" into the execution-layer block-header and EVM. This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block. With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO of L1. And thus with EIP-4788 the L1 beacon block root is made available. For the Ecotone upgrade, this entails that: The parent_beacon_block_root of the L1 origin is now embedded in the L2 block header. The \"Beacon roots contract\" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis. The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: Beacon Block Root","id":"112","title":"Ecotone: Beacon Block Root"},"113":{"body":"The Ethereum Node Record (ENR) for an Optimism execution node must contain an opel key-value pair where the key is opel and the value is a EIP-2124 fork id. The EL uses a different key from the CL in order to stop EL and CL nodes from connecting to each other.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » P2P Modifications","id":"113","title":"P2P Modifications"},"114":{"body":"Table of Contents Overview Driver Derivation L2 Output RPC method Structures BlockID L1BlockRef L2BlockRef SyncStatus Output Method API Protocol Version tracking","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node Specification","id":"114","title":"Rollup Node Specification"},"115":{"body":"The rollup node is the component responsible for deriving the L2 chain from L1 blocks (and their associated receipts ). The part of the rollup node that derives the L2 chain is called the rollup driver . This document is currently only concerned with the specification of the rollup driver.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Overview","id":"115","title":"Overview"},"116":{"body":"The task of the driver in the rollup node is to manage the derivation process: Keep track of L1 head block Keep track of the L2 chain sync progress Iterate over the derivation steps as new inputs become available","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Driver","id":"116","title":"Driver"},"117":{"body":"This process happens in three steps: Select inputs from the L1 chain, on top of the last L2 block: a list of blocks, with transactions and associated data and receipts. Read L1 information, deposits, and sequencing batches in order to generate payload attributes (essentially a block without output properties ). Pass the payload attributes to the execution engine , so that the L2 block (including output block properties ) may be computed. While this process is conceptually a pure function from the L1 chain to the L2 chain, it is in practice incremental. The L2 chain is extended whenever new L1 blocks are added to the L1 chain. Similarly, the L2 chain re-organizes whenever the L1 chain re-organizes . For a complete specification of the L2 block derivation, refer to the L2 block derivation document .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation","id":"117","title":"Derivation"},"118":{"body":"The Rollup node has its own RPC method, optimism_outputAtBlock which returns a 32 byte hash corresponding to the L2 output root .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » L2 Output RPC method","id":"118","title":"L2 Output RPC method"},"119":{"body":"These define the types used by rollup node API methods. The types defined here are extended from the engine API specs . BlockID hash: DATA, 32 Bytes number: QUANTITY, 64 Bits L1BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits L2BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits l1origin: BlockID sequenceNumber: QUANTITY, 64 Bits - distance to first block of epoch SyncStatus Represents a snapshot of the rollup driver. current_l1: Object - instance of L1BlockRef . current_l1_finalized: Object - instance of L1BlockRef . head_l1: Object - instance of L1BlockRef . safe_l1: Object - instance of L1BlockRef . finalized_l1: Object - instance of L1BlockRef . unsafe_l2: Object - instance of L2BlockRef . safe_l2: Object - instance of L2BlockRef . finalized_l2: Object - instance of L2BlockRef . pending_safe_l2: Object - instance of L2BlockRef . queued_unsafe_l2: Object - instance of L2BlockRef .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Structures","id":"119","title":"Structures"},"12":{"body":"Validity is defined as the ability for any party to execute the rollup state transition function, subject to certain lower bound expectations for available computing and bandwidth resources. Validity is also extended to refer to the ability for a smart contract on Ethereum to be able to validate this state transition function economically.","breadcrumbs":"Background » Validity","id":"12","title":"Validity"},"120":{"body":"The input and return types here are as defined by the engine API specs . method: optimism_outputAtBlock params: blockNumber: QUANTITY, 64 bits - L2 integer block number. returns: version: DATA, 32 Bytes - the output root version number, beginning with 0. outputRoot: DATA, 32 Bytes - the output root. blockRef: Object - instance of L2BlockRef . withdrawalStorageRoot: 32 bytes - storage root of the L2toL1MessagePasser contract. stateRoot: DATA: 32 bytes - the state root. syncStatus: Object - instance of SyncStatus .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Output Method API","id":"120","title":"Output Method API"},"121":{"body":"The rollup-node should monitor the recommended and required protocol version by monitoring the Protocol Version contract on L1, as specified in the Superchain Version Signaling specifications . This can be implemented through polling in the Driver loop. After polling the Protocol Version, the rollup node SHOULD communicate it with the execution-engine through an engine_signalSuperchainV1 call. The rollup node SHOULD warn the user when the recommended version is newer than the current version supported by the rollup node. The rollup node SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the rollup node operator.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Protocol Version tracking","id":"121","title":"Protocol Version tracking"},"122":{"body":"Table of Contents Overview P2P configuration Identification Discv5 Consensus Layer Structure LibP2P Transport Dialing NAT Peer management Transport security Protocol negotiation Identify Ping Multiplexing GossipSub Content-based message identification Message compression and limits Message ID computation Heartbeat and parameters Topic configuration Topic validation Gossip Topics blocksv1 blocksv2 blocksv3 Block encoding Block signatures Block validation Block processing Block topic scoring parameters Req-Resp payload_by_number","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Rollup-node P2P interface","id":"122","title":"Rollup-node P2P interface"},"123":{"body":"The rollup node has an optional peer-to-peer (P2P) network service to improve the latency between the view of sequencers and the rest of the network by bypassing the L1 in the happy case, without relying on a single centralized endpoint. This also enables faster historical sync to be bootstrapped by providing block headers to sync towards, and only having to compare the L2 chain inputs to the L1 data as compared to processing everything one block at a time. The rollup node will always prioritize L1 and reorganize to match the canonical chain. The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the \"unsafe\" chain, to improve the happy case performance. This also means that P2P behavior is a soft-rule: nodes keep each other in check with scoring and eventual banning of malicious peers by identity or IP. Any behavior on the P2P layer does not affect the rollup security, at worst nodes rely on higher-latency data from L1 to serve. In summary, the P2P stack looks like: Discovery to find peers: Discv5 Connections, peering, transport security, multiplexing, gossip: LibP2P Application-layer publishing and validation of gossiped messages like L2 blocks. This document only specifies the composition and configuration of these network libraries. These components have their own standards, implementations in Go/Rust/Java/Nim/JS/more, and are adopted by several other blockchains, most notably the L1 consensus layer (Eth2) .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Overview","id":"123","title":"Overview"},"124":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » P2P configuration","id":"124","title":"P2P configuration"},"125":{"body":"Nodes have a separate network- and consensus-identity. The network identity is a secp256k1 key, used for both discovery and active LibP2P connections. Common representations of network identity: PeerID: a LibP2P specific ID derived from the pubkey (through protobuf encoding, typing and hashing) NodeID: a Discv5 specific ID derived from the pubkey (through hashing, used in the DHT) Multi-address: an unsigned address, containing: IP, TCP port, PeerID ENR: a signed record used for discovery, containing: IP, TCP port, UDP port, signature (pubkey can be derived) and L2 network identification. Generally encoded in base64.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Identification","id":"125","title":"Identification"},"126":{"body":"Consensus Layer Structure The Ethereum Node Record (ENR) for an Optimism rollup node must contain the following values, identified by unique keys: An IPv4 address (ip field) and/or IPv6 address (ip6 field). A TCP port (tcp field) representing the local libp2p listening port. A UDP port (udp field) representing the local discv5 listening port. An OpStack (opstack field) L2 network identifier The opstack value is encoded as a single RLP bytes value, the concatenation of: chain ID (unsigned varint) fork ID (unsigned varint) Note that DiscV5 is a shared DHT (Distributed Hash Table): the L1 consensus and execution nodes, as well as testnet nodes, and even external IOT nodes, all communicate records in this large common DHT. This makes it more difficult to censor the discovery of node records. The discovery process in Optimism is a pipeline of node records: Fill the table with FINDNODES if necessary (Performed by Discv5 library) Pull additional records with searches to random Node IDs if necessary (e.g. iterate RandomNodes() in Go implementation) Pull records from the DiscV5 module when looking for peers Check if the record contains the opstack entry, verify it matches the chain ID and current or future fork number If not already connected, and not recently disconnected or put on deny-list, attempt to dial.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Discv5","id":"126","title":"Discv5"},"127":{"body":"Transport TCP transport. Additional transports are supported by LibP2P, but not required. Dialing Nodes should be publicly dialable, not rely on relay extensions, and able to dial both IPv4 and IPv6. NAT The listening endpoint must be publicly facing, but may be configured behind a NAT. LibP2P will use PMP / UPNP based techniques to track the external IP of the node. It is recommended to disable the above if the external IP is static and configured manually. Peer management The default is to maintain a peer count with a tide-system based on active peer count: At \"low tide\" the node starts to actively search for additional peer connections. At \"high tide\" the node starts to prune active connections, except those that are marked as trusted or have a grace period. Peers will have a grace period for a configurable amount of time after joining. In an emergency, when memory runs low, the node should start pruning more aggressively. Peer records can be persisted to disk to quickly reconnect with known peers after restarting the rollup node. The discovery process feeds the peerstore with peer records to connect to, tagged with a time-to-live (TTL). The current P2P processes do not require selective topic-specific peer connections, other than filtering for the basic network participation requirement. Peers may be banned if their performance score is too low, or if an objectively malicious action was detected. Banned peers will be persisted to the same data-store as the peerstore records. TODO: the connection gater does currently not gate by IP address on the dial Accept-callback. Transport security Libp2p-noise , XX handshake, with the secp256k1 P2P identity, as popularized in Eth2. The TLS option is available as well, but noise should be prioritized in negotiation. Protocol negotiation Multistream-select 1.0 (/multistream/1.0.0) is an interactive protocol used to negotiate sub-protocols supported in LibP2P peers. Multistream-select 2.0 may be used in the future. Identify LibP2P offers a minimal identification module to share client version and programming language. This is optional and can be disabled for enhanced privacy. It also includes the same protocol negotiation information, which can speed up initial connections. Ping LibP2P includes a simple ping protocol to track latency between connections. This should be enabled to help provide insight into the network health. Multiplexing For async communication over different channels over the same connection, multiplexing is used. mplex (/mplex/6.7.0) is required, and yamux (/yamux/1.0.0) is recommended but optional GossipSub GossipSub 1.1 (/meshsub/1.1.0, i.e. with peer-scoring extension) is a pubsub protocol for mesh-networks, deployed on L1 consensus (Eth2) and other protocols such as Filecoin, offering lots of customization options. Content-based message identification Messages are deduplicated, and filtered through application-layer signature verification. Thus origin-stamping is disabled and published messages must only contain application data, enforced through a StrictNoSign Signature Policy This provides greater privacy, and allows sequencers (consensus identity) to maintain multiple network identities for redundancy. Message compression and limits The application contents are compressed with snappy single-block-compression (as opposed to frame-compression), and constrained to 10 MiB. Message ID computation Same as L1 , with recognition of compression: If message.data has a valid snappy decompression, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_VALID_SNAPPY with the snappy decompressed message data, i.e. SHA256(MESSAGE_DOMAIN_VALID_SNAPPY + snappy_decompress(message.data))[:20]. Otherwise, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_INVALID_SNAPPY with the raw message data, i.e. SHA256(MESSAGE_DOMAIN_INVALID_SNAPPY + message.data)[:20]. Heartbeat and parameters GossipSub parameters : D (topic stable mesh target count): 8 D_low (topic stable mesh low watermark): 6 D_high (topic stable mesh high watermark): 12 D_lazy (gossip target): 6 heartbeat_interval (interval of heartbeat, in seconds): 0.5 fanout_ttl (ttl for fanout maps for topics we are not subscribed to but have published to, in seconds): 24 mcache_len (number of windows to retain full messages in cache for IWANT responses): 12 mcache_gossip (number of windows to gossip about): 3 seen_ttl (number of heartbeat intervals to retain message IDs): 130 (= 65 seconds) Notable differences from L1 consensus (Eth2): seen_ttl does not need to cover a full L1 epoch (6.4 minutes), but rather just a small window covering latest blocks fanout_ttl: adjusted to lower than seen_ttl mcache_len: a larger number of heartbeats can be retained since the gossip is much less noisy. heartbeat_interval: faster interval to reduce latency, bandwidth should still be reasonable since there are far fewer messages to gossip about each interval than on L1 which uses an interval of 0.7 seconds. Topic configuration Topics have string identifiers and are communicated with messages and subscriptions. /optimism/chain_id/hardfork_version/Name chain_id: replace with decimal representation of chain ID hardfork_version: replace with decimal representation of hardfork, starting at 0 Name: topic application-name Note that the topic encoding depends on the topic, unlike L1, since there are less topics, and all are snappy-compressed. Topic validation To ensure only valid messages are relayed, and malicious peers get scored based on application behavior, an extended validator checks the message before it is relayed or processed. The extended validator emits one of the following validation signals: ACCEPT valid, relayed to other peers and passed to local topic subscriber IGNORE scored like inactivity, message is dropped and not processed REJECT score penalties, message is dropped","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » LibP2P","id":"127","title":"LibP2P"},"128":{"body":"There are three topics for distributing blocks to other nodes faster than proxying through L1 would. These are:","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Gossip Topics","id":"128","title":"Gossip Topics"},"129":{"body":"Pre-Canyon/Shanghai blocks are broadcast on /optimism//0/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv1","id":"129","title":"blocksv1"},"13":{"body":"Availability is defined as the ability for any party to retrieve the inputs that are necessary to execute the rollup state transition function correctly. Availability is essentially an element of validity and is required to be able to guarantee validity in general. Similar to validity, availability is subject to lower bound resource requirements.","breadcrumbs":"Background » Availability","id":"13","title":"Availability"},"130":{"body":"Canyon/Delta blocks are broadcast on /optimism//1/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv2","id":"130","title":"blocksv2"},"131":{"body":"Ecotone blocks are broadcast on /optimism//2/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv3","id":"131","title":"blocksv3"},"132":{"body":"A block is structured as the concatenation of: V1 and V2 topics signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. V3 topic signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) parentBeaconBlockRoot: L1 origin parent beacon block root, always 32 bytes payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. All topics use Snappy block-compression (i.e. no snappy frames): the above needs to be compressed after encoding, and decompressed before decoding.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block encoding","id":"132","title":"Block encoding"},"133":{"body":"The signature is a secp256k1 signature, and signs over a message: keccak256(domain ++ chain_id ++ payload_hash), where: domain is 32 bytes, reserved for message types and versioning info. All zero for this signature. chain_id is a big-endian encoded uint256. payload_hash is keccak256(payload), where payload is the payload in V1 and V2, and parentBeaconBlockRoot ++ payload in V3. The secp256k1 signature must have y_parity = 1 or 0, the chain_id is already signed over.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block signatures","id":"133","title":"Block signatures"},"134":{"body":"An extended-validator checks the incoming messages as follows, in order of operation: [REJECT] if the compression is not valid [REJECT] if the block encoding is not valid [REJECT] if the payload.timestamp is older than 60 seconds in the past (graceful boundary for worst-case propagation and clock skew) [REJECT] if the payload.timestamp is more than 5 seconds into the future [REJECT] if the block_hash in the payload is not valid [REJECT] if the block is on the V1 topic and has withdrawals [REJECT] if the block is on the V1 topic and has a withdrawals list [REJECT] if the block is on a topic >= V2 and does not have an empty withdrawals list [REJECT] if the block is on a topic <= V2 and has a blob gas-used value set [REJECT] if the block is on a topic <= V2 and has an excess blob gas value set [REJECT] if the block is on a topic >= V3 and has a blob gas-used value that is not zero [REJECT] if the block is on a topic >= V3 and has an excess blob gas value that is not zero [REJECT] if the block is on a topic <= V2 and the parent beacon block root is not nil [REJECT] if the block is on a topic >= V3 and the parent beacon block root is nil [REJECT] if more than 5 different blocks have been seen with the same block height [IGNORE] if the block has already been seen [REJECT] if the signature by the sequencer is not valid Mark the block as seen for the given block height The block is signed by the corresponding sequencer, to filter malicious messages. The sequencer model is singular but may change to multiple sequencers in the future. A default sequencer pubkey is distributed with rollup nodes and should be configurable. Note that blocks that a block may still be propagated even if the L1 already confirmed a different block. The local L1 view of the node may be wrong, and the time and signature validation will prevent spam. Hence, calling into the execution engine with a block lookup every propagation step is not worth the added delay. Block processing A node may apply the block to their local engine ahead of L1 availability, if it ensures that: The application of the block is reversible, in case of a conflict with delayed L1 information The subsequent forkchoice-update ensures this block is recognized as \"unsafe\" (see fork choice updated ) Block topic scoring parameters TODO: GossipSub per-topic scoring to fine-tune incentives for ideal propagation delay and bandwidth usage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block validation","id":"134","title":"Block validation"},"135":{"body":"The op-node implements a similar request-response encoding for its sync protocols as the L1 ethereum Beacon-Chain. See L1 P2P-interface req-resp specification and Altair P2P update . However, the protocol is simplified, to avoid several issues seen in L1: Error strings in responses, if there is any alternative response, should not need to be compressed or have an artificial global length limit. Payload lengths should be fixed-length: byte-by-byte uvarint reading from the underlying stream is undesired. are relaxed to encode a uint32, rather than a beacon-chain ForkDigest. Payload-encoding may change per hardfork, so is not part of the protocol-ID. Usage of response-chunks is specific to the req-resp method: most basic req-resp does not need chunked responses. Compression is encouraged to be part of the payload-encoding, specific to the req-resp method, where necessary: pings and such do not need streaming frame compression etc. And the protocol ID format follows the same scheme as L1, except the trailing encoding schema part, which is now message-specific: /ProtocolPrefix/MessageName/SchemaVersion/ The req-resp protocols served by the op-node all have /ProtocolPrefix set to /opstack/req. Individual methods may include the chain ID as part of the /MessageName segment, so it's immediately clear which chain the method applies to, if the communication is chain-specific. Other methods may include chain-information in the request and/or response data, such as the ForkDigest in L1 beacon chain req-resp protocols. Each segment starts with a /, and may contain multiple /, and the final protocol ID is suffixed with a /.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Req-Resp","id":"135","title":"Req-Resp"},"136":{"body":"This is an optional chain syncing method, to request/serve execution payloads by number. This serves as a method to fill gaps upon missed gossip, and sync short to medium ranges of unsafe L2 blocks. Protocol ID: /opstack/req/payload_by_number//0/ /MessageName is /block_by_number/ where is set to the op-node L2 chain ID. /SchemaVersion is /0 Request format: : a little-endian uint64 - the block number to request. Response format: = is a byte code describing the result. 0 on success, should follow. 1 if valid request, but unavailable payload. 2 if invalid request 3+ if other error The >= 128 range is reserved for future use. is a little-endian uint32, identifying the response type (fork-specific) is an encoded block, read till stream EOF. The input of should be limited, as well as any generated decompressed output, to avoid unexpected resource usage or zip-bomb type attacks. A 10 MB limit is recommended, to ensure all blocks may be synced. Implementations may opt for a different limit, since this sync method is optional. list: 0: SSZ-encoded ExecutionPayload, with Snappy framing compression, matching the ExecutionPayload SSZ definition of the L1 Merge, L2 Bedrock and L2 Regolith, L2 Canyon versions. 1: SSZ-encoded ExecutionPayloadEnvelope with Snappy framing compression, matching the ExecutionPayloadEnvelope SSZ definition of the L2 Ecotone version. The request is by block-number, enabling parallel fetching of a chain across many peers. A res = 0 response should be verified to: Have a block-number matching the requested block number. Have a consistent blockhash w.r.t. the other block contents. Build towards a known canonical block. This can be verified by checking if the parent-hash of a previous trusted canonical block matches that of the verified hash of the retrieved block. For unsafe blocks this may be relaxed to verification against the parent-hash of any previously trusted block: The gossip validation process limits the amount of blocks that may be trusted to sync towards. The unsafe blocks should be queued for processing, the latest received L2 unsafe blocks should always override any previous chain, until the final L2 chain can be reproduced from L1 data. A res > 0 response code should not be accepted. The result code is helpful for debugging, but the client should regard any error like any other unanswered request, as the responding peer cannot be trusted.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » payload_by_number","id":"136","title":"payload_by_number"},"137":{"body":"Table of Contents Overview Eager Block Derivation Protocol Parameters Batch Submission Sequencing & Batch Submission Overview Batch Submission Wire Format Batcher Transaction Format Frame Format Channel Format Batch Format Architecture L2 Chain Derivation Pipeline L1 Traversal L1 Retrieval Frame Queue Channel Bank Pruning Timeouts Reading Loading frames Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue Engine API usage Bedrock, Canyon, Delta: API Usage Ecotone: API Usage Forkchoice synchronization L1-consolidation: payload attributes matching L1-sync: payload attributes processing Processing unsafe payload attributes Resetting the Pipeline Finding the sync starting point Resetting derivation stages About reorgs Post-Merge Deriving Payload Attributes Deriving the Transaction List Network upgrade automation transactions Ecotone L1Block Deployment GasPriceOracle Deployment L1Block Proxy Update GasPriceOracle Proxy Update GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) Building Individual Payload Attributes","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Specification","id":"137","title":"L2 Chain Derivation Specification"},"138":{"body":"Note the following assumes a single sequencer and batcher. In the future, the design will be adapted to accommodate multiple such entities. L2 chain derivation — deriving L2 blocks from L1 data — is one of the main responsibilities of the rollup node , both in validator mode, and in sequencer mode (where derivation acts as a sanity check on sequencing, and enables detecting L1 chain re-organizations ). The L2 chain is derived from the L1 chain. In particular, each L1 block following L2 chain inception is mapped to a sequencing epoch comprising at least one L2 block. Each L2 block belongs to exactly one epoch, and we call the corresponding L1 block its L1 origin . The epoch's number equals that of its L1 origin block. To derive the L2 blocks of epoch number E, we need the following inputs: L1 blocks in the range [E, E + SWS), called the sequencing window of the epoch, and SWS the sequencing window size. (Note that sequencing windows overlap.) Batcher transactions from blocks in the sequencing window. These transactions allow us to reconstruct the epoch's sequencer batches , each of which will produce one L2 block. Note that: The L1 origin will never contain any data needed to construct sequencer batches since each batch must contain the L1 origin hash. An epoch may have no sequencer batches. Deposits made in the L1 origin (in the form of events emitted by the deposit contract ). L1 block attributes from the L1 origin (to derive the L1 attributes deposited transaction ). The state of the L2 chain after the last L2 block of the previous epoch, or the L2 genesis state if E is the first epoch. To derive the whole L2 chain from scratch, we start with the L2 genesis state and the L2 genesis block as the first L2 block. We then derive L2 blocks from each epoch in order, starting at the first L1 block following L2 chain inception . Refer to the Architecture section for more information on how we implement this in practice. The L2 chain may contain pre-Bedrock history, but the L2 genesis here refers to the Bedrock L2 genesis block. Each L2 block with origin l1_origin is subject to the following constraints (whose values are denominated in seconds): block.timestamp = prev_l2_timestamp + l2_block_time prev_l2_timestamp is the timestamp of the L2 block immediately preceding this one. If there is no preceding block, then this is the genesis block, and its timestamp is explicitly specified. l2_block_time is a configurable parameter of the time between L2 blocks (2s on Optimism). l1_origin.timestamp <= block.timestamp <= max_l2_timestamp, where max_l2_timestamp = max(l1_origin.timestamp + max_sequencer_drift, prev_l2_timestamp + l2_block_time) max_sequencer_drift is a configurable parameter that bounds how far the sequencer can get ahead of the L1. Finally, each epoch must have at least one L2 block. The first constraint means there must be an L2 block every l2_block_time seconds following L2 chain inception. The second constraint ensures that an L2 block timestamp never precedes its L1 origin timestamp, and is never more than max_sequencer_drift ahead of it, except only in the unusual case where it might prohibit an L2 block from being produced every l2_block_time seconds. (Such cases might arise for example under a proof-of-work L1 that sees a period of rapid L1 block production.) In either case, the sequencer enforces len(batch.transactions) == 0 while max_sequencer_drift is exceeded. See Batch Queue for more details. The final requirement that each epoch must have at least one L2 block ensures that all relevant information from the L1 (e.g. deposits) is represented in the L2, even if it has no sequencer batches. Post-merge, Ethereum has a fixed 12s block time , though some slots can be skipped. Under a 2s L2 block time, we thus expect each epoch to typically contain 12/2 = 6 L2 blocks. The sequencer will however produce bigger epochs in order to maintain liveness in case of either a skipped slot on the L1 or a temporary loss of connection to it. For the lost connection case, smaller epochs might be produced after the connection was restored to keep L2 timestamps from drifting further and further ahead.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Overview","id":"138","title":"Overview"},"139":{"body":"Deriving an L2 block requires that we have constructed its sequencer batch and derived all L2 blocks and state updates prior to it. This means we can typically derive the L2 blocks of an epoch eagerly without waiting on the full sequencing window. The full sequencing window is required before derivation only in the very worst case where some portion of the sequencer batch for the first block of the epoch appears in the very last L1 block of the window. Note that this only applies to block derivation. Sequencer batches can still be derived and tentatively queued without deriving blocks from them.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Eager Block Derivation","id":"139","title":"Eager Block Derivation"},"14":{"body":"Generally speaking, there are three primary actors that interact with an OP Stack chain: users, sequencers, and verifiers. graph TD EthereumL1(Ethereum L1) subgraph \"L2 Participants\" Users(Users) Sequencers(Sequencers) Verifiers(Verifiers) end Verifiers -.->|fetch transaction batches| EthereumL1 Verifiers -.->|fetch deposit data| EthereumL1 Verifiers -->|submit/validate/challenge output proposals| EthereumL1 Verifiers -.->|fetch realtime P2P updates| Sequencers Users -->|submit deposits/withdrawals| EthereumL1 Users -->|submit transactions| Sequencers Users -->|query data| Verifiers Sequencers -->|submit transaction batches| EthereumL1 Sequencers -.->|fetch deposit data| EthereumL1 classDef l1Contracts stroke:#bbf,stroke-width:2px; classDef l2Components stroke:#333,stroke-width:2px; classDef systemUser stroke:#f9a,stroke-width:2px; class EthereumL1 l1Contracts; class Users,Sequencers,Verifiers l2Components;","breadcrumbs":"Background » Network Participants","id":"14","title":"Network Participants"},"140":{"body":"The following table gives an overview of some protocol parameters, and how they are affected by protocol upgrades. Parameter Bedrock (default) value Latest (default) value Changes Notes max_sequencer_drift 600 1800 Fjord Changed from a chain parameter to a constant with Fjord. MAX_RLP_BYTES_PER_CHANNEL 10,000,000 100,000,000 Fjord Constant increased with Fjord. MAX_CHANNEL_BANK_SIZE 100,000,000 1,000,000,000 Fjord Constant increased with Fjord. MAX_SPAN_BATCH_ELEMENT_COUNT 10,000,000 10,000,000 Effectively introduced in Fjord Number of elements","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Protocol Parameters","id":"140","title":"Protocol Parameters"},"141":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission","id":"141","title":"Batch Submission"},"142":{"body":"The sequencer accepts L2 transactions from users. It is responsible for building blocks out of these. For each such block, it also creates a corresponding sequencer batch . It is also responsible for submitting each batch to a data availability provider (e.g. Ethereum calldata), which it does via its batcher component. The difference between an L2 block and a batch is subtle but important: the block includes an L2 state root, whereas the batch only commits to transactions at a given L2 timestamp (equivalently: L2 block number). A block also includes a reference to the previous block (*). (*) This matters in some edge case where a L1 reorg would occur and a batch would be reposted to the L1 chain but not the preceding batch, whereas the predecessor of an L2 block cannot possibly change. This means that even if the sequencer applies a state transition incorrectly, the transactions in the batch will still be considered part of the canonical L2 chain. Batches are still subject to validity checks (i.e. they have to be encoded correctly), and so are individual transactions within the batch (e.g. signatures have to be valid). Invalid batches and invalid individual transactions within an otherwise valid batch are discarded by correct nodes. If the sequencer applies a state transition incorrectly and posts an output root , then this output root will be incorrect. The incorrect output root will be challenged by a fault proof , then replaced by a correct output root for the existing sequencer batches. Refer to the Batch Submission specification for more information.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Sequencing & Batch Submission Overview","id":"142","title":"Sequencing & Batch Submission Overview"},"143":{"body":"Batch submission is closely tied to L2 chain derivation because the derivation process must decode the batches that have been encoded for the purpose of batch submission. The batcher submits batcher transactions to a data availability provider . These transactions contain one or multiple channel frames , which are chunks of data belonging to a channel . A channel is a sequence of sequencer batches (for any L2 blocks) compressed together. The reason to group multiple batches together is simply to obtain a better compression rate, hence reducing data availability costs. Channels might be too large to fit in a single batcher transaction , hence we need to split it into chunks known as channel frames . A single batcher transaction can also carry multiple frames (belonging to the same or to different channels). This design gives use the maximum flexibility in how we aggregate batches into channels, and split channels over batcher transactions. It notably allows us to maximize data utilization in a batcher transaction: for instance it allows us to pack the final (small) frame of one channel with one or more frames from the next channel. Also note that we use a streaming compression scheme, and we do not need to know how many batches a channel will end up containing when we start a channel, or even as we send the first frames in the channel. And by splitting channels across multiple data transactions, the L2 can have larger block data than the data-availability layer may support. All of this is illustrated in the following diagram. Explanations below. batch derivation chain diagram The first line represents L1 blocks with their numbers. The boxes under the L1 blocks represent batcher transactions included within the block. The squiggles under the L1 blocks represent deposits (more specifically, events emitted by the deposit contract ). Each colored chunk within the boxes represents a channel frame . So A and B are channels whereas A0, A1, B0, B1, B2 are frames. Notice that: multiple channels are interleaved frames do not need to be transmitted in order a single batcher transaction can carry frames from multiple channels In the next line, the rounded boxes represent individual sequencer batches that were extracted from the channels. The four blue/purple/pink were derived from channel A while the other were derived from channel B. These batches are here represented in the order they were decoded from batches (in this case B is decoded first). Note The caption here says \"Channel B was seen first and will be decoded into batches first\", but this is not a requirement. For instance, it would be equally acceptable for an implementation to peek into the channels and decode the one that contains the oldest batches first. The rest of the diagram is conceptually distinct from the first part and illustrates L2 chain derivation after the channels have been reordered. The first line shows batcher transactions. Note that in this case, there exists an ordering of the batches that makes all frames within the channels appear contiguously. This is not true in general. For instance, in the second transaction, the position of A1 and B0 could have been inverted for exactly the same result — no changes needed in the rest of the diagram. The second line shows the reconstructed channels in proper order. The third line shows the batches extracted from the channel. Because the channels are ordered and the batches within a channel are sequential, this means the batches are ordered too. The fourth line shows the L2 block derived from each batch. Note that we have a 1-1 batch to block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there are \"gaps\" in the batches posted on L1. The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while the second number (the \"sequence number\") denotes the position within the epoch. Finally, the sixth line shows user-deposited transactions derived from the deposit contract event mentioned earlier. Note the 101-0 L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if frame B2 indicates that it is the last frame within the channel and (2) no empty blocks must be inserted. The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4 blocks, because the last frame of channel A appears in block 102, but belong to epoch 99. As for the comment on \"security types\", it explains the classification of blocks as used on L1 and L2. Unsafe L2 blocks : Safe L2 blocks : Finalized L2 blocks: refer to block that have been derived from finalized L1 data. These security levels map to the headBlockHash, safeBlockHash and finalizedBlockHash values transmitted when interacting with the execution-engine API .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission Wire Format","id":"143","title":"Batch Submission Wire Format"},"144":{"body":"Batcher transactions are encoded as version_byte ++ rollup_payload (where ++ denotes concatenation). version_byte rollup_payload 0 frame ... (one or more frames, concatenated) 1 da_commitment (experimental, see alt-da ) Unknown versions make the batcher transaction invalid (it must be ignored by the rollup node). All frames in a batcher transaction must be parseable. If any one frame fails to parse, the all frames in the transaction are rejected. Batch transactions are authenticated by verifying that the to address of the transaction matches the batch inbox address, and the from address matches the batch-sender address in the system configuration at the time of the L1 block that the transaction data is read from.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batcher Transaction Format","id":"144","title":"Batcher Transaction Format"},"145":{"body":"A channel frame is encoded as: frame = channel_id ++ frame_number ++ frame_data_length ++ frame_data ++ is_last channel_id = bytes16\nframe_number = uint16\nframe_data_length = uint32\nframe_data = bytes\nis_last = bool Where uint32 and uint16 are all big-endian unsigned integers. Type names should be interpreted to and encoded according to the Solidity ABI . All data in a frame is fixed-size, except the frame_data. The fixed overhead is 16 + 2 + 4 + 1 = 23 bytes. Fixed-size frame metadata avoids a circular dependency with the target total data length, to simplify packing of frames with varying content length. where: channel_id is an opaque identifier for the channel. It should not be reused and is suggested to be random; however, outside of timeout rules, it is not checked for validity frame_number identifies the index of the frame within the channel frame_data_length is the length of frame_data in bytes. It is capped to 1,000,000 bytes. frame_data is a sequence of bytes belonging to the channel, logically after the bytes from the previous frames is_last is a single byte with a value of 1 if the frame is the last in the channel, 0 if there are frames in the channel. Any other value makes the frame invalid (it must be ignored by the rollup node).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Format","id":"145","title":"Frame Format"},"146":{"body":"A channel is encoded by applying a streaming compression algorithm to a list of batches: rlp_batches = []\nfor batch in batches: rlp_batches.append(batch) where: batches is the input, a sequence of batches byte-encoded as per the next section (\"Batch Encoding\") rlp_batches is the concatenation of the RLP-encoded batches channel_encoding = zlib_compress(rlp_batches) where zlib_compress is the ZLIB algorithm (as specified in RFC-1950 ) with no dictionary. The Fjord upgrade introduces an additional versioned channel encoding format to support alternate compression algorithms. When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL (defined in the Protocol Parameters table ), in order to avoid \"zip-bomb\" types of attack (where a small compressed input decompresses to a humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained only the first MAX_RLP_BYTES_PER_CHANNEL decompressed bytes. The limit is set on RLP decoding, so all batches that can be decoded in MAX_RLP_BYTES_PER_CHANNEL will be accepted even if the size of the channel is greater than MAX_RLP_BYTES_PER_CHANNEL. The exact requirement is that length(input) <= MAX_RLP_BYTES_PER_CHANNEL. While the above pseudocode implies that all batches are known in advance, it is possible to perform streaming compression and decompression of RLP-encoded batches. This means it is possible to start including channel frames in a batcher transaction before we know how many batches (and how many frames) the channel will contain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Format","id":"146","title":"Channel Format"},"147":{"body":"Recall that a batch contains a list of transactions to be included in a specific L2 block. A batch is encoded as batch_version ++ content, where content depends on the batch_version. Prior to the Delta upgrade, batches all have batch_version 0 and are encoded as described below. batch_version content 0 rlp_encode([parent_hash, epoch_number, epoch_hash, timestamp, transaction_list]) where: batch_version is a single byte, prefixed before the RLP contents, alike to transaction typing. rlp_encode is a function that encodes a batch according to the RLP format , and [x, y, z] denotes a list containing items x, y and z parent_hash is the block hash of the previous L2 block epoch_number and epoch_hash are the number and hash of the L1 block corresponding to the sequencing epoch of the L2 block timestamp is the timestamp of the L2 block transaction_list is an RLP-encoded list of EIP-2718 encoded transactions. The Delta upgrade introduced an additional batch type, span batches . Unknown versions make the batch invalid (it must be ignored by the rollup node), as do malformed contents. The epoch_number and the timestamp must also respect the constraints listed in the Batch Queue section, otherwise the batch is considered invalid and will be ignored.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Format","id":"147","title":"Batch Format"},"148":{"body":"The above primarily describes the general encodings used in L2 chain derivation, primarily how batches are encoded within batcher transactions . This section describes how the L2 chain is produced from the L1 batches using a pipeline architecture. A verifier may implement this differently, but must be semantically equivalent to not diverge from the L2 chain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Architecture","id":"148","title":"Architecture"},"149":{"body":"Our architecture decomposes the derivation process into a pipeline made up of the following stages: L1 Traversal L1 Retrieval Frame Queue Channel Bank Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue The data flows from the start (outer) of the pipeline towards the end (inner). From the innermost stage the data is pulled from the outermost stage. However, data is processed in reverse order. Meaning that if there is any data to be processed in the last stage, it will be processed first. Processing proceeds in \"steps\" that can be taken at each stage. We try to take as many steps as possible in the last (most inner) stage before taking any steps in its outer stage, etc. This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing the derivation pipeline. Each stage can maintain its own inner state as necessary. In particular, each stage maintains a L1 block reference (number + hash) to the latest L1 block such that all data originating from previous blocks has been fully processed, and the data from that block is being or has been processed. This allows the innermost stage to account for finalization of the L1 data-availability used to produce the L2 chain, to reflect in the L2 chain forkchoice when the L2 chain inputs become irreversible. Let's briefly describe each stage of the pipeline.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Pipeline","id":"149","title":"L2 Chain Derivation Pipeline"},"15":{"body":"Users are the general class of network participants who: Submit transactions through a Sequencer or by interacting with contracts on Ethereum. Query transaction data from interfaces operated by verifiers.","breadcrumbs":"Background » Users","id":"15","title":"Users"},"150":{"body":"In the L1 Traversal stage, we simply read the header of the next L1 block. In normal operations, these will be new L1 blocks as they get created, though we can also read old blocks while syncing, or in case of an L1 re-org . Upon traversal of the L1 block, the system configuration copy used by the L1 retrieval stage is updated, such that the batch-sender authentication is always accurate to the exact L1 block that is read by the stage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Traversal","id":"150","title":"L1 Traversal"},"151":{"body":"In the L1 Retrieval stage, we read the block we get from the outer stage (L1 traversal), and extract data from its batcher transactions . A batcher transaction is one with the following properties: The to field is equal to the configured batcher inbox address. The sender, as recovered from the transaction signature (v, r, and s), is the batcher address loaded from the system config matching the L1 block of the data. Each batcher transaction is versioned and contains a series of channel frames to be read by the Frame Queue, see Batch Submission Wire Format . Each batcher transaction in the block is processed in the order they appear in the block by passing its calldata on to the next phase.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Retrieval","id":"151","title":"L1 Retrieval"},"152":{"body":"The Frame Queue buffers one data-transaction at a time, decoded into channel frames , to be consumed by the next stage. See Batcher transaction format and Frame format specifications.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Queue","id":"152","title":"Frame Queue"},"153":{"body":"The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1 retrieval stage. A step in the channel bank stage tries to read data from channels that are \"ready\". Channels are currently fully buffered until read or dropped, streaming channels may be supported in a future version of the ChannelBank. To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels. Channels are recorded in FIFO order in a structure called the channel queue . A channel is added to the channel queue the first time a frame belonging to the channel is seen. Pruning After successfully inserting a new frame, the ChannelBank is pruned: channels are dropped in FIFO order, until total_size <= MAX_CHANNEL_BANK_SIZE, where: total_size is the sum of the sizes of each channel, which is the sum of all buffered frame data of the channel, with an additional frame-overhead of 200 bytes per frame. MAX_CHANNEL_BANK_SIZE is a protocol constant defined in the Protocol Parameters table . Timeouts The L1 origin that the channel was opened in is tracked with the channel as channel.open_l1_block, and determines the maximum span of L1 blocks that the channel data is retained for, before being pruned. A channel is timed out if: current_l1_block.number > channel.open_l1_block.number + CHANNEL_TIMEOUT, where: current_l1_block is the L1 origin that the stage is currently traversing. CHANNEL_TIMEOUT is a rollup-configurable, expressed in number of L1 blocks. New frames for timed-out channels are dropped instead of buffered. Reading Upon reading, while the first opened channel is timed-out, remove it from the channel-bank. Prior to the Canyon network upgrade, once the first opened channel, if any, is not timed-out and is ready, then it is read and removed from the channel-bank. After the Canyon network upgrade, the entire channel bank is scanned in FIFO order (by open time) & the first ready (i.e. not timed-out) channel will be returned. The canyon behavior will activate when frames from a L1 block whose timestamp is greater than or equal to the canyon time first enter the channel queue. A channel is ready if: The channel is closed The channel has a contiguous sequence of frames until the closing frame If no channel is ready, the next frame is read and ingested into the channel bank. Loading frames When a channel ID referenced by a frame is not already present in the Channel Bank, a new channel is opened, tagged with the current L1 block, and appended to the channel-queue. Frame insertion conditions: New frames matching timed-out channels that have not yet been pruned from the channel-bank are dropped. Duplicate frames (by frame number) for frames that have not been pruned from the channel-bank are dropped. Duplicate closes (new frame is_last == 1, but the channel has already seen a closing frame and has not yet been pruned from the channel-bank) are dropped. If a frame is closing (is_last == 1) any existing higher-numbered frames are removed from the channel. Note that while this allows channel IDs to be reused once they have been pruned from the channel-bank, it is recommended that batcher implementations use unique channel IDs.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Bank","id":"153","title":"Channel Bank"},"154":{"body":"In this stage, we decompress the channel we pull from the last stage, and then parse batches from the decompressed byte stream. See Channel Format and Batch Format for decompression and decoding specification.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Reader (Batch Decoding)","id":"154","title":"Channel Reader (Batch Decoding)"},"155":{"body":"During the Batch Buffering stage, we reorder batches by their timestamps. If batches are missing for some time slots and a valid batch with a higher timestamp exists, this stage also generates empty batches to fill the gaps. Batches are pushed to the next stage whenever there is one sequential batch directly following the timestamp of the current safe L2 head (the last block that can be derived from the canonical L1 chain). The parent hash of the batch must also match the hash of the current safe L2 head. Note that the presence of any gaps in the batches derived from L1 means that this stage will need to buffer for a whole sequencing window before it can generate empty batches (because the missing batch(es) could have data in the last L1 block of the window in the worst case). A batch can have 4 different forms of validity: drop: the batch is invalid, and will always be in the future, unless we reorg. It can be removed from the buffer. accept: the batch is valid and should be processed. undecided: we are lacking L1 information until we can proceed batch filtering. future: the batch may be valid, but cannot be processed yet and should be checked again later. The batches are processed in order of the inclusion on L1: if multiple batches can be accept-ed the first is applied. An implementation can defer future batches a later derivation step to reduce validation work. The batches validity is derived as follows: Definitions: batch as defined in the Batch format section . epoch = safe_l2_head.l1_origin a L1 origin coupled to the batch, with properties: number (L1 block number), hash (L1 block hash), and timestamp (L1 block timestamp). inclusion_block_number is the L1 block number when batch was first fully derived, i.e. decoded and output by the previous stage. next_timestamp = safe_l2_head.timestamp + block_time is the expected L2 timestamp the next batch should have, see block time information . next_epoch may not be known yet, but would be the L1 block after epoch if available. batch_origin is either epoch or next_epoch, depending on validation. Note that processing of a batch can be deferred until batch.timestamp <= next_timestamp, since future batches will have to be retained anyway. Rules, in validation order: batch.timestamp > next_timestamp -> future: i.e. the batch must be ready to process. batch.timestamp < next_timestamp -> drop: i.e. the batch must not be too old. batch.parent_hash != safe_l2_head.hash -> drop: i.e. the parent hash must be equal to the L2 safe head block hash. batch.epoch_num + sequence_window_size < inclusion_block_number -> drop: i.e. the batch must be included timely. batch.epoch_num < epoch.number -> drop: i.e. the batch origin is not older than that of the L2 safe head. batch.epoch_num == epoch.number: define batch_origin as epoch. batch.epoch_num == epoch.number+1: If next_epoch is not known -> undecided: i.e. a batch that changes the L1 origin cannot be processed until we have the L1 origin data. If known, then define batch_origin as next_epoch batch.epoch_num > epoch.number+1 -> drop: i.e. the L1 origin cannot change by more than one L1 block per L2 block. batch.epoch_hash != batch_origin.hash -> drop: i.e. a batch must reference a canonical L1 origin, to prevent batches from being replayed onto unexpected L1 chains. batch.timestamp < batch_origin.time -> drop: enforce the min L2 timestamp rule. batch.timestamp > batch_origin.time + max_sequencer_drift: enforce the L2 timestamp drift rule, but with exceptions to preserve above min L2 timestamp invariant: len(batch.transactions) == 0: epoch.number == batch.epoch_num: this implies the batch does not already advance the L1 origin, and must thus be checked against next_epoch. If next_epoch is not known -> undecided: without the next L1 origin we cannot yet determine if time invariant could have been kept. If batch.timestamp >= next_epoch.time -> drop: the batch could have adopted the next L1 origin without breaking the L2 time >= L1 time invariant. len(batch.transactions) > 0: -> drop: when exceeding the sequencer time drift, never allow the sequencer to include transactions. batch.transactions: drop if the batch.transactions list contains a transaction that is invalid or derived by other means exclusively: any transaction that is empty (zero length byte string) any deposited transactions (identified by the transaction type prefix byte) If no batch can be accept-ed, and the stage has completed buffering of all batches that can fully be read from the L1 block at height epoch.number + sequence_window_size, and the next_epoch is available, then an empty batch can be derived with the following properties: parent_hash = safe_l2_head.hash timestamp = next_timestamp transactions is empty, i.e. no sequencer transactions. Deposited transactions may be added in the next stage. If next_timestamp < next_epoch.time: the current L1 origin is repeated, to preserve the L2 time invariant. epoch_num = epoch.number epoch_hash = epoch.hash If the batch is the first batch of the epoch, that epoch is used instead of advancing the epoch to ensure that there is at least one L2 block per epoch. epoch_num = epoch.number epoch_hash = epoch.hash Otherwise, epoch_num = next_epoch.number epoch_hash = next_epoch.hash","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Queue","id":"155","title":"Batch Queue"},"156":{"body":"In the Payload Attributes Derivation stage, we convert the batches we get from the previous stage into instances of the PayloadAttributes structure. Such a structure encodes the transactions that need to figure into a block, as well as other block inputs (timestamp, fee recipient, etc). Payload attributes derivation is detailed in the section Deriving Payload Attributes section below. This stage maintains its own copy of the system configuration , independent of the L1 retrieval stage. The system configuration is updated with L1 log events whenever the L1 epoch referenced by the batch input changes.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Payload Attributes Derivation","id":"156","title":"Payload Attributes Derivation"},"157":{"body":"In the Engine Queue stage, the previously derived PayloadAttributes structures are buffered and sent to the execution engine to be executed and converted into a proper L2 block. The stage maintains references to three L2 blocks: The finalized L2 head : everything up to and including this block can be fully derived from the finalized (i.e. canonical and forever irreversible) part of the L1 chain. The safe L2 head : everything up to and including this block can be fully derived from the currently canonical L1 chain. The unsafe L2 head : blocks between the safe and unsafe heads are unsafe blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer mode) or from unsafe sync to the sequencer (in validator mode). This is also known as the \"latest\" head. Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references from which L1 blocks each was derived. This history does not have to be complete, but enables later L1 finality signals to be translated into L2 finality. Engine API usage To interact with the engine, the execution engine API is used, with the following JSON-RPC methods: Bedrock, Canyon, Delta: API Usage engine_forkchoiceUpdatedV2 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV2 — retrieves a previously requested execution payload build. engine_newPayloadV2 — executes an execution payload to create a block. Ecotone: API Usage engine_forkchoiceUpdatedV3 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV3 — retrieves a previously requested execution payload build. engine_newPayload engine_newPayloadV2 — executes a Bedrock/Canyon/Delta execution payload to create a block. engine_newPayloadV3 — executes an Ecotone execution payload to create a block. The current version of op-node uses the v3 Engine API RPC methods as well as engine_newPayloadV2, due to engine_newPayloadV3 only supporting Ecotone execution payloads. Both engine_forkchoiceUpdatedV3 and engine_getPayloadV3 are backwards compatible with Bedrock, Canyon & Delta payloads. Prior versions of op-node used v2 and v1 methods. The execution payload is an object of type ExecutionPayloadV3 . The ExecutionPayload has the following requirements: Bedrock The withdrawals field MUST be nil The blob gas used field MUST be nil The blob gas limit field MUST be nil Canyon, Delta The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be nil The blob gas limit field MUST be nil Ecotone The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be 0 The blob gas limit field MUST be 0 Forkchoice synchronization If there are any forkchoice updates to be applied, before additional inputs are derived or processed, then these are applied to the engine first. This synchronization may happen when: A L1 finality signal finalizes one or more L2 blocks: updating the \"finalized\" L2 block. A successful consolidation of unsafe L2 blocks: updating the \"safe\" L2 block. The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state. The new forkchoice state is applied by calling fork choice updated on the engine API. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. L1-consolidation: payload attributes matching If the unsafe head is ahead of the safe head, then consolidation is attempted, verifying that existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data. During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If the payload attributes match this oldest unsafe L2 block, then that block can be considered \"safe\" and becomes the new safe head. The following fields of the derived L2 payload attributes are checked for equality with the L2 block: Bedrock, Canyon, Delta, Ecotone Blocks parent_hash timestamp randao fee_recipient transactions_list (first length, then equality of each of the encoded transactions, including deposits) gas_limit Canyon, Delta, Ecotone Blocks withdrawals (first presence, then length, then equality of each of the encoded withdrawals) Ecotone Blocks parent_beacon_block_root If consolidation succeeds, the forkchoice change will synchronize as described in the section above. If consolidation fails, the L2 payload attributes will be processed immediately as described in the section below. The payload attributes are chosen in favor of the previous unsafe L2 block, creating an L2 chain reorg on top of the current safe block. Immediately processing the new alternative attributes enables execution engines like go-ethereum to enact the change, as linear rewinds of the tip of the chain may not be supported. L1-sync: payload attributes processing If the safe and unsafe L2 heads are identical (whether because of failed consolidation or not), we send the L2 payload attributes to the execution engine to be constructed into a proper L2 block. This L2 block will then become both the new L2 safe and unsafe head. If a payload attributes created from a batch cannot be inserted into the chain because of a validation error (i.e. there was an invalid transaction or state transition in the block) the batch should be dropped & the safe head should not be advanced. The engine queue will attempt to use the next batch for that timestamp from the batch queue. If no valid batch is found, the rollup node will create a deposit only batch which should always pass validation because deposits are always valid. Interaction with the execution engine via the execution engine API is detailed in the Communication with the Execution Engine section. The payload attributes are then processed with a sequence of: Engine: Fork choice updated with current forkchoice state of the stage, and the attributes to start block building. Non-deterministic sources, like the tx-pool, must be disabled to reconstruct the expected block. Engine: Get Payload to retrieve the payload, by the payload-ID in the result of the previous step. Engine: New Payload to import the new payload into the execution engine. Engine: Fork Choice Updated to make the new payload canonical, now with a change of both safe and unsafe fields to refer to the payload, and no payload attributes. Engine API Error handling: On RPC-type errors the payload attributes processing should be re-attempted in a future step. On payload processing errors the attributes must be dropped, and the forkchoice state must be left unchanged. Eventually the derivation pipeline will produce alternative payload attributes, with or without batches. If the payload attributes only contained deposits, then it is a critical derivation error if these are invalid. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. Processing unsafe payload attributes If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as an \"unsafe\" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the user to see the head of the L2 chain faster than the L1 may confirm the L2 batches. To process unsafe payloads, the payload must: Have a block number higher than the current safe L2 head. The safe L2 head may only be reorged out due to L1 reorgs. Have a parent blockhash that matches the current unsafe L2 head. This prevents the execution engine individually syncing a larger gap in the unsafe L2 chain. This prevents unsafe L2 blocks from reorging other previously validated L2 blocks. This check may change in the future versions to adopt e.g. the L1 snap-sync protocol. The payload is then processed with a sequence of: Bedrock/Canyon/Delta Payloads engine_newPayloadV2: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV2: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Ecotone Payloads engine_newPayloadV3: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV3: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Engine API Error handling: On RPC-type errors the payload processing should be re-attempted in a future step. On payload processing errors the payload must be dropped, and not be marked as canonical. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Engine Queue","id":"157","title":"Engine Queue"},"158":{"body":"It is possible to reset the pipeline, for instance if we detect an L1 reorg (reorganization) . This enables the rollup node to handle L1 chain reorg events. Resetting will recover the pipeline into a state that produces the same outputs as a full L2 derivation process, but starting from an existing L2 chain that is traversed back just enough to reconcile with the current L1 chain. Note that this algorithm covers several important use-cases: Initialize the pipeline without starting from 0, e.g. when the rollup node restarts with an existing engine instance. Recover the pipeline if it becomes inconsistent with the execution engine chain, e.g. when the engine syncs/changes. Recover the pipeline when the L1 chain reorganizes, e.g. a late L1 block is orphaned, or a larger attestation failure. Initialize the pipeline to derive a disputed L2 block with prior L1 and L2 history inside a fault-proof program. Handling these cases also means a node can be configured to eagerly sync L1 data with 0 confirmations, as it can undo the changes if the L1 later does recognize the data as canonical, enabling safe low-latency usage. The Engine Queue is first reset, to determine the L1 and L2 starting points to continue derivation from. After this, the other stages are reset independent of each other. Finding the sync starting point To find the starting point, there are several steps, relative to the head of the chain traversing back: Find the current L2 forkchoice state If no finalized block can be found, start at the Bedrock genesis block. If no safe block can be found, fallback to the finalized block. The unsafe block should always be available and consistent with the above (it may not be in rare engine-corruption recovery cases, this is being reviewed). Find the first L2 block with plausible L1 reference to be the new unsafe starting point, starting from previous unsafe, back to finalized and no further. Plausible iff: the L1 origin of the L2 block is known and canonical, or unknown and has a block-number ahead of L1. Find the first L2 block with an L1 reference older than the sequencing window, to be the new safe starting point, starting at the above plausible unsafe head, back to finalized and no further. If at any point the L1 origin is known but not canonical, the unsafe head is revised to parent of the current. The highest L2 block with known canonical L1 origin is remembered as highest. If at any point the L1 origin in the block is corrupt w.r.t. derivation rules, then error. Corruption includes: Inconsistent L1 origin block number or parent-hash with parent L1 origin Inconsistent L1 sequence number (always changes to 0 for a L1 origin change, or increments by 1 if not) If the L1 origin of the L2 block n is older than the L1 origin of highest by more than a sequence window, and n.sequence_number == 0, then the parent L2 block of n will be the safe starting point. The finalized L2 block persists as the finalized starting point. Find the first L2 block with an L1 reference older than the channel-timeout The L1 origin referenced by this block which we call l2base will be the base for the L2 pipeline derivation: By starting here, the stages can buffer any necessary data, while dropping incomplete derivation outputs until L1 traversal has caught up with the actual L2 safe head. While traversing back the L2 chain, an implementation may sanity-check that the starting point is never set too far back compared to the existing forkchoice state, to avoid an intensive reorg because of misconfiguration. Implementers note: step 1-4 are known as FindL2Heads. Step 5 is currently part of the Engine Queue reset. This may change to isolate the starting-point search from the bare reset logic. Resetting derivation stages L1 Traversal: start at L1 base as first block to be pulled by next stage. L1 Retrieval: empty previous data, and fetch the base L1 data, or defer the fetching work to a later pipeline step. Frame Queue: empty the queue. Channel Bank: empty the channel bank. Channel Reader: reset any batch decoding state. Batch Queue: empty the batch queue, use base as initial L1 point of reference. Payload Attributes Derivation: empty any batch/attributes state. Engine Queue: Initialize L2 forkchoice state with syncing start point state. (finalized/safe/unsafe) Initialize the L1 point of reference of the stage to base. Require a forkchoice update as first task Reset any finality data Where necessary, stages starting at base can initialize their system-config from data encoded in the l2base block. About reorgs Post-Merge Note that post- merge , the depth of reorgs will be bounded by the L1 finality delay (2 L1 beacon epochs, or approximately 13 minutes, unless more than 1/3 of the network consistently disagrees). New L1 blocks may be finalized every L1 beacon epoch (approximately 6.4 minutes), and depending on these finality-signals and batch-inclusion, the derived L2 chain will become irreversible as well. Note that this form of finalization only affects inputs, and nodes can then subjectively say the chain is irreversible, by reproducing the chain from these irreversible inputs and the set protocol rules and parameters. This is however completely unrelated to the outputs posted on L1, which require a form of proof like a fault-proof or zk-proof to finalize. Optimistic-rollup outputs like withdrawals on L1 are only labeled \"finalized\" after passing a week without dispute (fault proof challenge window), a name-collision with the proof-of-stake finalization.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Resetting the Pipeline","id":"158","title":"Resetting the Pipeline"},"159":{"body":"For every L2 block derived from L1 data, we need to build payload attributes , represented by an expanded version of the PayloadAttributesV2 object, which includes additional transactions and noTxPool fields. This process happens during the payloads-attributes queue ran by a verifier node, as well as during block-production ran by a sequencer node (the sequencer may enable the tx-pool usage if the transactions are batch-submitted).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving Payload Attributes","id":"159","title":"Deriving Payload Attributes"},"16":{"body":"Sequencers fill the role of the block producer on an OP Stack chain. Chains may have a single Sequencer or may choose to utilize some consensus protocol that coordinates multiple Sequencers. The OP Stack currently officially only supports a single active Sequencer at any given time. In general, specifications may use the term \"the Sequencer\" as a stand-in for either a single Sequencer or a consensus protocol of multiple Sequencers. The Sequencer: Accepts transactions directly from Users. Observes \"deposit\" transactions generated on Ethereum. Consolidates both transaction streams into ordered L2 blocks. Submits information to L1 that is sufficient to fully reproduce those L2 blocks. Provides real-time access to pending L2 blocks that have not yet been confirmed on L1. The Sequencer serves an important role for the operation of an L2 chain but is not a trusted actor. The Sequencer is generally responsible for improving the user experience by ordering transactions much more quickly and cheaply than would currently be possible if users were to submit all transactions directly to L1.","breadcrumbs":"Background » Sequencers","id":"16","title":"Sequencers"},"160":{"body":"For each L2 block to be created by the sequencer, we start from a sequencer batch matching the target L2 block number. This could potentially be an empty auto-generated batch, if the L1 chain did not include a batch for the target L2 block number. Remember that the batch includes a sequencing epoch number, an L2 timestamp, and a transaction list. This block is part of a sequencing epoch , whose number matches that of an L1 block (its L1 origin ). This L1 block is used to derive L1 attributes and (for the first L2 block in the epoch) user deposits. Therefore, a PayloadAttributesV2 object must include the following transactions: one or more deposited transactions , of two kinds: a single L1 attributes deposited transaction , derived from the L1 origin. for the first L2 block in the epoch, zero or more user-deposited transactions , derived from the receipts of the L1 origin. zero or more network upgrade automation transactions : special transactions to perform network upgrades. zero or more sequenced transactions : regular transactions signed by L2 users, included in the sequencer batch. Transactions must appear in this order in the payload attributes. The L1 attributes are read from the L1 block header, while deposits are read from the L1 block's receipts . Refer to the deposit contract specification for details on how deposits are encoded as log entries.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving the Transaction List","id":"160","title":"Deriving the Transaction List"},"161":{"body":"Some network upgrades require automated contract changes or deployments at specific blocks. To automate these, without adding persistent changes to the execution-layer, special transactions may be inserted as part of the derivation process. Ecotone The Ecotone hardfork activation block contains the following transactions, in this order: L1 Attributes Transaction, using the pre-Ecotone setL1BlockValues User deposits from L1 Network Upgrade Transactions L1Block deployment GasPriceOracle deployment Update L1Block Proxy ERC-1967 Implementation Slot Update GasPriceOracle Proxy ERC-1967 Implementation Slot GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) To not modify or interrupt the system behavior around gas computation, this block will not include any sequenced transactions by setting noTxPool: true. L1Block Deployment The L1Block contract is upgraded to process the new Ecotone L1-data-fee parameters and L1 blob base-fee. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000000 to: null mint: 0 value: 0 gasLimit: 375,000 data: 0x60806040523480156100105... ( full bytecode ) sourceHash: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Deployment\" This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000000\nComputed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Deployment\"))\n# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json This transaction MUST deploy a contract with the following code hash 0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd. GasPriceOracle Deployment The GasPriceOracle contract is upgraded to support the new Ecotone L1-data-fee parameters. Post fork this contract will use the blob base fee to compute the gas price for L1-data-fee transactions. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000001 to: null, mint: 0 value: 0 gasLimit: 1,000,000 data: 0x60806040523480156100... ( full bytecode ) sourceHash: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Deployment\" This results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000001\nComputed Address: 0xb528D11cC114E026F138fE568744c6D45ce6Da7A Verify sourceHash: ❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Deployment\"))\n# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json This transaction MUST deploy a contract with the following code hash 0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5. L1Block Proxy Update This transaction updates the L1Block Proxy ERC-1967 implementation slot to point to the new L1Block deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x4200000000000000000000000000000000000015 (L1Block Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff sourceHash: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)\n0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Proxy Update\"))\n# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc GasPriceOracle Proxy Update This transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a sourceHash: 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: Gas Price Oracle Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)\n0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Proxy Update\"))\n# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a GasPriceOracle Enable Ecotone This transaction informs the GasPriceOracle to start using the Ecotone gas calculation formula. A deposit transaction is derived with the following attributes: from: 0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 (Depositer Account) to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 80,000 data: 0x22b90ab3 sourceHash: 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Set Ecotone\" Verify data: cast sig \"setEcotone()\"\n0x22b90ab3 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Set Ecotone\"))\n# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93 Beacon block roots contract deployment (EIP-4788) EIP-4788 introduces a \"Beacon block roots\" contract, that processes and exposes the beacon-block-root values. at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02. For deployment, EIP-4788 defines a pre- EIP-155 legacy transaction, sent from a key that is derived such that the transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code. However, this type of transaction requires manual deployment and gas-payments. And since the processing is an integral part of the chain processing, and has to be repeated for every OP-Stack chain, the deployment is approached differently here. Some chains may already have a user-submitted instance of the EIP-4788 transaction. This is cryptographically guaranteed to be correct, but may result in the upgrade transaction deploying a second contract, with the next nonce. The result of this deployment can be ignored. A Deposit transaction is derived with the following attributes: from: 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875, as specified in the EIP. to: null mint: 0 value: 0 gasLimit: 0x3d090, as specified in the EIP. isCreation: true data: 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500 isSystemTx: false, as per the Regolith upgrade, even the system-generated transactions spend gas. sourceHash: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c, computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: beacon block roots contract deployment\" The contract address upon deployment is computed as rlp([sender, nonce]), which will equal: BEACON_ROOTS_ADDRESS if deployed a different address (0xE3aE1Ae551eeEda337c0BfF6C4c7cbA98dce353B) if nonce = 1: when a user already submitted the EIP transaction before the upgrade. Verify BEACON_ROOTS_ADDRESS: cast compute-address --nonce=0 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875\n# Computed Address: 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: beacon block roots contract deployment\"))\n# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Network upgrade automation transactions","id":"161","title":"Network upgrade automation transactions"},"162":{"body":"After deriving the transactions list, the rollup node constructs a PayloadAttributesV2 as follows: timestamp is set to the batch's timestamp. random is set to the prev_randao L1 block attribute. suggestedFeeRecipient is set to the Sequencer Fee Vault address. See Fee Vaults specification. transactions is the array of the derived transactions: deposited transactions and sequenced transactions, all encoded with EIP-2718 . noTxPool is set to true, to use the exact above transactions list when constructing the block. gasLimit is set to the current gasLimit value in the system configuration of this payload. withdrawals is set to nil prior to Canyon and an empty array after Canyon","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Building Individual Payload Attributes","id":"162","title":"Building Individual Payload Attributes"},"163":{"body":"Table of Contents Overview","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Batch Submitter","id":"163","title":"Batch Submitter"},"164":{"body":"The batch submitter, also referred to as the batcher, is the entity submitting the L2 sequencer data to L1, to make it available for verifiers. The format of the data transactions is defined in the derivation spec : the data is constructed from L2 blocks in the reverse order as it is derived from data into L2 blocks. The timing, operation and transaction signing is implementation-specific: any data can be submitted at any time, but only the data that matches the derivation spec rules will be valid from the verifier perspective. The most minimal batcher implementation can be defined as a loop of the following operations: See if the unsafe L2 block number is past the safe block number: unsafe data needs to be submitted. Iterate over all unsafe L2 blocks, skip any that were previously submitted. Open a channel, buffer all the L2 block data to be submitted, while applying the encoding and compression as defined in the derivation spec . Pull frames from the channel to fill data transactions with, until the channel is empty. Submit the data transactions to L1 The L2 view of safe/unsafe does not instantly update after data is submitted, nor when it gets confirmed on L1, so special care may have to be taken to not duplicate data submissions.","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Overview","id":"164","title":"Overview"},"165":{"body":"Table of Contents Overview Pre-image Oracle Pre-image key types Type 0: Zero key Type 1: Local key Type 2: Global keccak256 key Type 3: Global generic key Type 4: Global SHA2-256 key Type 5: Global EIP-4844 Point-evaluation key Type 6: Global Precompile key Type 7-128: reserved range Type 129-255: application usage Bootstrapping Hinting Pre-image communication Fault Proof Program Prologue Main content Epilogue Pre-image hinting routes l1-block-header l1-transactions l1-receipts l1-precompile l2-block-header l2-transactions l2-code l2-state-node l2-output Precompile Accelerators Fault Proof VM Fault Proof Interactive Dispute Game","breadcrumbs":"OP Stack Protocol » Fault Proof » Fault Proof","id":"165","title":"Fault Proof"},"166":{"body":"A fault proof, also known as fraud proof or interactive game, consists of 3 components: Program : given a commitment to all rollup inputs (L1 data) and the dispute, verify the dispute statelessly. VM : given a stateless program and its inputs, trace any instruction step, and prove it on L1. Interactive Dispute Game : bisect a dispute down to a single instruction, and resolve the base-case using the VM. Each of these 3 components may have different implementations, which can be combined into different proof stacks, and contribute to proof diversity when resolving a dispute. \"Stateless execution\" of the program, and its individual instructions, refers to reproducing the exact same computation by authenticating the inputs with a Pre-image Oracle . Diagram of Program and VM architecture","breadcrumbs":"OP Stack Protocol » Fault Proof » Overview","id":"166","title":"Overview"},"167":{"body":"The pre-image oracle is the only form of communication between the Program (in the Client role) and the VM (in the Server role). The program uses the pre-image oracle to query any input data that is understood to be available to the user: The initial inputs to bootstrap the program. See Bootstrapping . External data not already part of the program code. See Pre-image hinting routes . The communication happens over a simple request-response wire protocol, see Pre-image communication .","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image Oracle","id":"167","title":"Pre-image Oracle"},"168":{"body":"Pre-images are identified by a bytes32 type-prefixed key: The first byte identifies the type of request. The remaining 31 bytes identify the pre-image key. Type 0: Zero key The zero prefix is illegal. This ensures all pre-image keys are non-zero, enabling storage lookup optimizations and avoiding easy mistakes with invalid zeroed keys in the EVM. Type 1: Local key Information specific to the dispute: the remainder of the key may be an index, a string, a hash, etc. Only the contract(s) managing this dispute instance may serve the value for this key: it is localized and context-dependent. This type of key is used for program bootstrapping, to identify the initial input arguments by index or name. Type 2: Global keccak256 key This type of key uses a global pre-image store contract, and is fully context-independent and permissionless. I.e. every key must have a single unique value, regardless of chain history or time. Using a global store reduces duplicate pre-image registration work, and avoids unnecessary contract redeployments per dispute. This global store contract should be non-upgradeable. Since keccak256 is a safe 32-byte hash input, the first byte is overwritten with a 2 to derive the key, while keeping the rest of the key \"readable\" (matching the original hash). Type 3: Global generic key Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments. This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:], where: x is a bytes32, which can be a hash of an arbitrary-length type of cryptographically secure commitment. sender is a bytes32 identifying the pre-image inserter address (left-padded to 32 bytes) This global store contract should be non-upgradeable. The global contract is permissionless: users can standardize around external contracts that verify pre-images (i.e. a specific sender will always be trusted for a specific kind of pre-image). The external contract verifies the pre-image before inserting it into the global store for usage by all fault proof VMs without requiring the VM or global store contract to be changed. Users may standardize around upgradeable external pre-image contracts, in case the implementation of the verification of the pre-image is expected to change. The store update function is update(x bytes32, offset uint64, span uint8, value bytes32): x is the bytes32 x that the pre-image key is computed with. Only part of the pre-image, starting at offset, and up to (incl.) 32 bytes span can be inserted at a time. Pre-images may have an undefined length (e.g. a stream), we only need to know how many bytes of value are usable. The key and offset will be hashed together to uniquely store the value and span, for later pre-image serving. This enables fault proof programs to adopt any new pre-image schemes without VM update or contract redeployment. It is up to the user to index the special pre-image values by this key scheme, as there is no way to revert it to the original commitment without knowing said commitment or value. Type 4: Global SHA2-256 key A SHA-256 pre-image. Key: the SHA-256 hash, with the first byte overwritten with the type byte: 4 ++ sha256(data)[1:]. Type 5: Global EIP-4844 Point-evaluation key An EIP-4844 point-evaluation. In an EIP-4844 blob, 4096 field elements represent the blob data. It verifies p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof. The value y is the pre-image. The value z is part of the key; the index of the point within the blob. The commitment is part of the key. Each element is proven with a point-evaluation. Key: 5 ++ keccak256(commitment ++ z)[1:], where: 5 is the type byte ++ is concatenation commitment is a bytes48, representing the KZG commitment. z is a big-endian uint256 Type 6: Global Precompile key A precompile result. It maps directly to precompiles on Ethereum. This preimage key can be used to avoid running expensive precompile operations in the program. Key: 6 ++ keccak256(precompile ++ input)[1:], where: 6 is the type byte ++ is concatenation precompile is the 20-byte address of the precompile contract input is the input to the precompile contract The result is identical to that of a call to the precompile contract, prefixed with a revert indicator: reverted ++ precompile_result. reverted is a 1-byte indicator with a 0 value if the precompile reverts for the given input, otherwise it's 1. Type 7-128: reserved range Range start and end both inclusive. This range of key types is reserved for future usage by the core protocol. E.g. version changes, contract migrations, chain-data, additional core features, etc. 128 specifically (1000 0000 in binary) is reserved for key-type length-extension (reducing the content part to 30 or less key bytes), if the need arises. Type 129-255: application usage This range of key types may be used by forks or customized versions of the fault proof protocol.","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image key types","id":"168","title":"Pre-image key types"},"169":{"body":"Initial inputs are deterministic, but not necessarily singular or global: there may be multiple different disputes at the same time, each with its own disputed claims and L1 context. To bootstrap, the program requests the initial inputs from the VM, using pre-image key type 1. The VM is aware of the external context, and maps requested pre-image keys based on their type, i.e. a local lookup for type 1, or global one for 2, and optionally support other key-types.","breadcrumbs":"OP Stack Protocol » Fault Proof » Bootstrapping","id":"169","title":"Bootstrapping"},"17":{"body":"Verifiers download and execute the L2 state transition function independently of the Sequencer. Verifiers help to maintain the integrity of the network and serve blockchain data to Users. Verifiers generally: Download rollup data from L1 and the Sequencer. Use rollup data to execute the L2 state transition function. Serve rollup data and computed L2 state information to Users. Verifiers can also act as Proposers and/or Challengers who: Submit assertions about the state of the L2 to a smart contract on L1. Validate assertions made by other participants. Dispute invalid assertions made by other participants.","breadcrumbs":"Background » Verifiers","id":"17","title":"Verifiers"},"170":{"body":"There is one more form of optional communication between client and server: pre-image hinting. Hinting is optional, and is a no-op in a L1 VM implementation. The hint itself comes at very low cost onchain: the hint can be a single write sys-call, which is instant as the memory to write as hint does not actually need to be loaded as part of the onchain proof. Hinting allows the program, when generating a proof offchain, to instruct the VM what data it is interested in. The VM can choose to execute the requested hint at any time: either locally (for standard requests), or in a modular form by redirecting the hint to tooling that may come with the VM program. Hints do not have to be executed directly: they may first just be logged to show the intents of the program, and the latest hint may be buffered for lazy execution, or dropped entirely when in read-only mode (like onchain). When the pre-image oracle serves a request, and the request cannot be served from an existing collection of pre-images (e.g. a local pre-image cache) then the VM can execute the hint to retrieve the missing pre-image(s). It is the responsibility of the program to provide sufficient hinting for every pre-image request. Some hints may have to be repeated: the VM only has to execute the last hint when handling a missing pre-image. Note that hints may produce multiple pre-images: e.g. a hint for an ethereum block with transaction list may prepare pre-images for the header, each of the transactions, and the intermediate merkle-nodes that form the transactions-list Merkle Patricia Trie. Hinting is implemented with a request-acknowledgement wire-protocol over a blocking two-way stream: := := := big-endian uint32 # length of \n := byte sequence\n := 1-byte zero value The ack informs the client that the hint has been processed. Servers may respond to hints and pre-image (see below) requests asynchronously as they are on separate streams. To avoid requesting pre-images that are not yet fetched, clients should request the pre-image only after it has observed the hint acknowledgement.","breadcrumbs":"OP Stack Protocol » Fault Proof » Hinting","id":"170","title":"Hinting"},"171":{"body":"Pre-images are communicated with a minimal wire-protocol over a blocking two-way stream. This protocol can be implemented with blocking read/write syscalls. :=
A new SystemConfig UpdateType is introduced that enables the modification of EIP-1559 parameters. This allows for the chain @@ -302,39 +255,6 @@
e This function returns the currently configured EIP-1559 denominator. function eip1559Denominator()(uint64) -Fee Vault Config -For each FeeVault, there is a setter for its config. The arguments to the setter include -the RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork. -Each of these functions should be public and only callable by the chain governor. -Each function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType. -setBaseFeeVaultConfig -function setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork) - -setL1FeeVaultConfig -function setL1FeeVaultConfig(address,uint256,WithdrawalNetwork) - -setSequencerFeeVaultConfig -function setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork) - -OptimismPortal -The OptimismPortal is updated to emit a special system TransactionDeposited event. -Interface -setConfig -The setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig -is the single source of truth for chain operator ownership. -function setConfig(ConfigType,bytes) - -This function emits a TransactionDeposited event. -event TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData); - -The following fields are included: - -from is the DEPOSITOR_ACCOUNT -to is Predeploys.L1Block -version is uint256(0) -opaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit -is 200_000, isCreation is false and the data is abi.encodeCall(L1Block.setConfig, (_type, _value)) - diff --git a/protocol/messengers.html b/protocol/messengers.html index 5719b0eac..b0c6745a4 100644 --- a/protocol/messengers.html +++ b/protocol/messengers.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/overview.html b/protocol/overview.html index 19a171b6b..8d974911d 100644 --- a/protocol/overview.html +++ b/protocol/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/precompiles.html b/protocol/precompiles.html index 2636bcded..591225781 100644 --- a/protocol/precompiles.html +++ b/protocol/precompiles.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/predeploys.html b/protocol/predeploys.html index f69344d63..18f80ecc9 100644 --- a/protocol/predeploys.html +++ b/protocol/predeploys.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/preinstalls.html b/protocol/preinstalls.html index a3e678702..de25cd1f4 100644 --- a/protocol/preinstalls.html +++ b/protocol/preinstalls.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/proposals.html b/protocol/proposals.html index 4356aed7b..c7e27aba0 100644 --- a/protocol/proposals.html +++ b/protocol/proposals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/regolith/overview.html b/protocol/regolith/overview.html index 25fb28a59..735c8d392 100644 --- a/protocol/regolith/overview.html +++ b/protocol/regolith/overview.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node-p2p.html b/protocol/rollup-node-p2p.html index 6b7b877ad..f733fce32 100644 --- a/protocol/rollup-node-p2p.html +++ b/protocol/rollup-node-p2p.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/rollup-node.html b/protocol/rollup-node.html index 7b2194855..74e7465df 100644 --- a/protocol/rollup-node.html +++ b/protocol/rollup-node.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/safe-extensions.html b/protocol/safe-extensions.html index c13615619..4601198ba 100644 --- a/protocol/safe-extensions.html +++ b/protocol/safe-extensions.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/stage-1.html b/protocol/stage-1.html index d28f06461..2659aa26c 100644 --- a/protocol/stage-1.html +++ b/protocol/stage-1.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-configuration.html b/protocol/superchain-configuration.html index ee7a3f560..6796bb40e 100644 --- a/protocol/superchain-configuration.html +++ b/protocol/superchain-configuration.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/superchain-upgrades.html b/protocol/superchain-upgrades.html index e9ac90b28..aad45a9b2 100644 --- a/protocol/superchain-upgrades.html +++ b/protocol/superchain-upgrades.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/system-config.html b/protocol/system-config.html index afbdefd92..d5fe843f1 100644 --- a/protocol/system-config.html +++ b/protocol/system-config.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/protocol/withdrawals.html b/protocol/withdrawals.html index e390c5450..8596661a9 100644 --- a/protocol/withdrawals.html +++ b/protocol/withdrawals.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/root.html b/root.html index 20d712d67..bd978d50b 100644 --- a/root.html +++ b/root.html @@ -97,7 +97,7 @@ - 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. Configurability4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary + 1. Introduction2. Background3. OP Stack Protocol3.1. Bridges3.1.1. Messengers3.1.2. Deposits3.1.3. Withdrawals3.1.4. Guaranteed Gas Market3.1.5. Proposals3.2. Clients3.2.1. Execution Engine3.2.2. Rollup Node3.2.2.1. Rollup Node P2P3.2.2.2. Derivation3.2.3. Batch Submitter3.3. Fault Proof3.3.1. Cannon Fault Proof VM3.3.2. Stage One Decentralization3.3.2.1. Dispute Game Interface3.3.2.2. Fault Dispute Game3.3.2.2.1. Honest Challenger3.3.2.2.2. Bond Incentives3.3.2.3. Bridge Integration3.4. Precompiles3.5. Predeploys3.6. Preinstalls3.7. Superchain3.7.1. Superchain Configuration3.7.2. Superchain Upgrades3.8. System Config3.9. Configurability3.10. Safe Extensions3.10.1. Stage 1 Roles and Requirements3.11. Protocol Upgrades3.11.1. Regolith3.11.2. Canyon3.11.3. Delta3.11.3.1. Span Batches3.11.4. Ecotone3.11.4.1. Derivation3.11.4.2. L1 attributes3.11.5. Fjord3.11.5.1. Execution Engine3.11.5.2. Derivation3.11.5.3. Predeploys3.11.6. Granite3.11.6.1. Execution Engine3.11.6.2. Derivation3.11.7. Holocene3.11.7.1. Derivation3.11.7.2. Execution Engine3.11.7.3. Predeploys3.11.7.4. System Config4. Governance4.1. Governance Token5. Experimental5.1. Custom Gas Token5.2. Alt-DA5.3. Interoperability5.3.1. Dependency Set5.3.2. Messaging5.3.3. Predeploys5.3.4. Sequencer5.3.5. Verifier5.3.6. Rollup Node P2P5.3.7. Fault Proof5.3.8. Upgrade5.3.9. Token Bridging5.3.10. SuperchainWETH5.3.11. Derivation5.3.12. Transaction Pool5.4. OP Contracts Manager5.5. Governance Token6. Glossary diff --git a/searchindex.js b/searchindex.js index 371b06267..623744500 100644 --- a/searchindex.js +++ b/searchindex.js @@ -1 +1 @@ -Object.assign(window.search, {"doc_urls":["root.html#op-stack-specification","root.html#about-optimism","root.html#about-the-op-stack","root.html#site-navigation","background.html#background","background.html#overview","background.html#foundations","background.html#ethereum-scalability","background.html#optimistic-rollups","background.html#evm-equivalence","background.html#protocol-guarantees","background.html#liveness","background.html#validity","background.html#availability","background.html#network-participants","background.html#users","background.html#sequencers","background.html#verifiers","background.html#key-interaction-diagrams","background.html#depositing-and-sending-transactions","background.html#withdrawing","background.html#next-steps","protocol/overview.html#optimism-overview","protocol/overview.html#architecture-design-goals","protocol/overview.html#architecture-overview","protocol/overview.html#core-l1-smart-contracts","protocol/overview.html#core-l2-smart-contracts","protocol/overview.html#smart-contract-proxies","protocol/overview.html#l2-node-components","protocol/overview.html#transactionblock-propagation","protocol/overview.html#key-interactions-in-depth","protocol/overview.html#deposits","protocol/overview.html#block-derivation","protocol/overview.html#engine-api","protocol/bridges.html#standard-bridges","protocol/bridges.html#overview","protocol/bridges.html#token-depositing","protocol/bridges.html#upgradability","protocol/messengers.html#cross-domain-messengers","protocol/messengers.html#overview","protocol/messengers.html#message-passing","protocol/messengers.html#upgradability","protocol/messengers.html#message-versioning","protocol/messengers.html#message-version-0","protocol/messengers.html#message-version-1","protocol/messengers.html#backwards-compatibility-notes","protocol/deposits.html#deposits","protocol/deposits.html#overview","protocol/deposits.html#the-deposited-transaction-type","protocol/deposits.html#source-hash-computation","protocol/deposits.html#kinds-of-deposited-transactions","protocol/deposits.html#validation-and-authorization-of-deposited-transactions","protocol/deposits.html#execution","protocol/deposits.html#deposit-receipt","protocol/deposits.html#l1-attributes-deposited-transaction","protocol/deposits.html#l1-attributes-deposited-transaction-calldata","protocol/deposits.html#special-accounts-on-l2","protocol/deposits.html#l1-attributes-depositor-account","protocol/deposits.html#l1-attributes-predeployed-contract","protocol/deposits.html#user-deposited-transactions","protocol/deposits.html#deposit-contract","protocol/withdrawals.html#withdrawals","protocol/withdrawals.html#overview","protocol/withdrawals.html#withdrawal-flow","protocol/withdrawals.html#on-l2","protocol/withdrawals.html#on-l1","protocol/withdrawals.html#the-l2tol1messagepasser-contract","protocol/withdrawals.html#addresses-are-not-aliased-on-withdrawals","protocol/withdrawals.html#the-optimism-portal-contract","protocol/withdrawals.html#withdrawal-verification-and-finalization","protocol/withdrawals.html#security-considerations","protocol/withdrawals.html#key-properties-of-withdrawal-verification","protocol/withdrawals.html#handling-successfully-verified-messages-that-fail-when-relayed","protocol/withdrawals.html#optimismportal-can-send-arbitrary-messages-on-l1","protocol/guaranteed-gas-market.html#guaranteed-gas-fee-market","protocol/guaranteed-gas-market.html#overview","protocol/guaranteed-gas-market.html#gas-stipend","protocol/guaranteed-gas-market.html#default-values","protocol/guaranteed-gas-market.html#limiting-guaranteed-gas","protocol/guaranteed-gas-market.html#rationale-for-burning-l1-gas","protocol/guaranteed-gas-market.html#on-preventing-griefing-attacks","protocol/proposals.html#l2-output-root-proposals-specification","protocol/proposals.html#overview","protocol/proposals.html#proposing-l2-output-commitments","protocol/proposals.html#l2outputoracle-v100","protocol/proposals.html#l2-output-commitment-construction","protocol/proposals.html#l2-output-oracle-smart-contract","protocol/proposals.html#configuration","protocol/proposals.html#security-considerations","protocol/proposals.html#l1-reorgs","protocol/exec-engine.html#l2-execution-engine","protocol/exec-engine.html#1559-parameters","protocol/exec-engine.html#deposited-transaction-processing","protocol/exec-engine.html#deposited-transaction-boundaries","protocol/exec-engine.html#fees","protocol/exec-engine.html#fee-vaults","protocol/exec-engine.html#priority-fees-sequencer-fee-vault","protocol/exec-engine.html#base-fees-base-fee-vault","protocol/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/exec-engine.html#engine-api","protocol/exec-engine.html#engine_forkchoiceupdatedv2","protocol/exec-engine.html#engine_forkchoiceupdatedv3","protocol/exec-engine.html#engine_newpayloadv2","protocol/exec-engine.html#engine_newpayloadv3","protocol/exec-engine.html#engine_getpayloadv2","protocol/exec-engine.html#engine_getpayloadv3","protocol/exec-engine.html#engine_signalsuperchainv1","protocol/exec-engine.html#networking","protocol/exec-engine.html#sync","protocol/exec-engine.html#happy-path-sync","protocol/exec-engine.html#worst-case-sync","protocol/exec-engine.html#ecotone-disable-blob-transactions","protocol/exec-engine.html#ecotone-beacon-block-root","protocol/exec-engine.html#p2p-modifications","protocol/rollup-node.html#rollup-node-specification","protocol/rollup-node.html#overview","protocol/rollup-node.html#driver","protocol/rollup-node.html#derivation","protocol/rollup-node.html#l2-output-rpc-method","protocol/rollup-node.html#structures","protocol/rollup-node.html#output-method-api","protocol/rollup-node.html#protocol-version-tracking","protocol/rollup-node-p2p.html#rollup-node-p2p-interface","protocol/rollup-node-p2p.html#overview","protocol/rollup-node-p2p.html#p2p-configuration","protocol/rollup-node-p2p.html#identification","protocol/rollup-node-p2p.html#discv5","protocol/rollup-node-p2p.html#libp2p","protocol/rollup-node-p2p.html#gossip-topics","protocol/rollup-node-p2p.html#blocksv1","protocol/rollup-node-p2p.html#blocksv2","protocol/rollup-node-p2p.html#blocksv3","protocol/rollup-node-p2p.html#block-encoding","protocol/rollup-node-p2p.html#block-signatures","protocol/rollup-node-p2p.html#block-validation","protocol/rollup-node-p2p.html#req-resp","protocol/rollup-node-p2p.html#payload_by_number","protocol/derivation.html#l2-chain-derivation-specification","protocol/derivation.html#overview","protocol/derivation.html#eager-block-derivation","protocol/derivation.html#protocol-parameters","protocol/derivation.html#batch-submission","protocol/derivation.html#sequencing--batch-submission-overview","protocol/derivation.html#batch-submission-wire-format","protocol/derivation.html#batcher-transaction-format","protocol/derivation.html#frame-format","protocol/derivation.html#channel-format","protocol/derivation.html#batch-format","protocol/derivation.html#architecture","protocol/derivation.html#l2-chain-derivation-pipeline","protocol/derivation.html#l1-traversal","protocol/derivation.html#l1-retrieval","protocol/derivation.html#frame-queue","protocol/derivation.html#channel-bank","protocol/derivation.html#channel-reader-batch-decoding","protocol/derivation.html#batch-queue","protocol/derivation.html#payload-attributes-derivation","protocol/derivation.html#engine-queue","protocol/derivation.html#resetting-the-pipeline","protocol/derivation.html#deriving-payload-attributes","protocol/derivation.html#deriving-the-transaction-list","protocol/derivation.html#network-upgrade-automation-transactions","protocol/derivation.html#building-individual-payload-attributes","protocol/batcher.html#batch-submitter","protocol/batcher.html#overview","fault-proof/index.html#fault-proof","fault-proof/index.html#overview","fault-proof/index.html#pre-image-oracle","fault-proof/index.html#pre-image-key-types","fault-proof/index.html#bootstrapping","fault-proof/index.html#hinting","fault-proof/index.html#pre-image-communication","fault-proof/index.html#fault-proof-program","fault-proof/index.html#prologue","fault-proof/index.html#main-content","fault-proof/index.html#epilogue","fault-proof/index.html#pre-image-hinting-routes","fault-proof/index.html#precompile-accelerators","fault-proof/index.html#fault-proof-vm","fault-proof/index.html#fault-proof-interactive-dispute-game","fault-proof/cannon-fault-proof-vm.html#cannon-fault-proof-virtual-machine","fault-proof/cannon-fault-proof-vm.html#overview","fault-proof/cannon-fault-proof-vm.html#state","fault-proof/cannon-fault-proof-vm.html#state-hash","fault-proof/cannon-fault-proof-vm.html#memory","fault-proof/cannon-fault-proof-vm.html#heap","fault-proof/cannon-fault-proof-vm.html#delay-slots","fault-proof/cannon-fault-proof-vm.html#syscalls","fault-proof/cannon-fault-proof-vm.html#io","fault-proof/cannon-fault-proof-vm.html#standard-streams","fault-proof/cannon-fault-proof-vm.html#hint-communication","fault-proof/cannon-fault-proof-vm.html#pre-image-communication","fault-proof/cannon-fault-proof-vm.html#exceptions","fault-proof/cannon-fault-proof-vm.html#security-model","fault-proof/cannon-fault-proof-vm.html#compiler-correctness","fault-proof/cannon-fault-proof-vm.html#compiler-assumptions","fault-proof/stage-one/index.html#stage-one-decentralization","fault-proof/stage-one/dispute-game-interface.html#dispute-game-interface","fault-proof/stage-one/dispute-game-interface.html#overview","fault-proof/stage-one/dispute-game-interface.html#types","fault-proof/stage-one/dispute-game-interface.html#disputegamefactory-interface","fault-proof/stage-one/dispute-game-interface.html#disputegame-interface","fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game","fault-proof/stage-one/fault-dispute-game.html#overview","fault-proof/stage-one/fault-dispute-game.html#definitions","fault-proof/stage-one/fault-dispute-game.html#virtual-machine-vm","fault-proof/stage-one/fault-dispute-game.html#preimageoracle","fault-proof/stage-one/fault-dispute-game.html#execution-trace","fault-proof/stage-one/fault-dispute-game.html#claims","fault-proof/stage-one/fault-dispute-game.html#anchor-state","fault-proof/stage-one/fault-dispute-game.html#anchor-state-registry","fault-proof/stage-one/fault-dispute-game.html#dag","fault-proof/stage-one/fault-dispute-game.html#subgame","fault-proof/stage-one/fault-dispute-game.html#game-tree","fault-proof/stage-one/fault-dispute-game.html#position","fault-proof/stage-one/fault-dispute-game.html#max_clock_duration","fault-proof/stage-one/fault-dispute-game.html#clock_extension","fault-proof/stage-one/fault-dispute-game.html#freeloader-claims","fault-proof/stage-one/fault-dispute-game.html#core-game-mechanics","fault-proof/stage-one/fault-dispute-game.html#actors","fault-proof/stage-one/fault-dispute-game.html#moves","fault-proof/stage-one/fault-dispute-game.html#l2-block-number-challenge","fault-proof/stage-one/fault-dispute-game.html#step","fault-proof/stage-one/fault-dispute-game.html#step-types","fault-proof/stage-one/fault-dispute-game.html#preimageoracle-interaction","fault-proof/stage-one/fault-dispute-game.html#team-dynamics","fault-proof/stage-one/fault-dispute-game.html#game-clock","fault-proof/stage-one/fault-dispute-game.html#resolution","fault-proof/stage-one/fault-dispute-game.html#finalization","fault-proof/stage-one/honest-challenger-fdg.html#honest-challenger-fault-dispute-game","fault-proof/stage-one/honest-challenger-fdg.html#overview","fault-proof/stage-one/honest-challenger-fdg.html#invariants","fault-proof/stage-one/honest-challenger-fdg.html#fault-dispute-game-responses","fault-proof/stage-one/honest-challenger-fdg.html#moves","fault-proof/stage-one/honest-challenger-fdg.html#steps","fault-proof/stage-one/honest-challenger-fdg.html#timeliness","fault-proof/stage-one/honest-challenger-fdg.html#resolution","fault-proof/stage-one/bond-incentives.html#bond-incentives","fault-proof/stage-one/bond-incentives.html#overview","fault-proof/stage-one/bond-incentives.html#moves","fault-proof/stage-one/bond-incentives.html#subgame-resolution","fault-proof/stage-one/bond-incentives.html#leftmost-claim-incentives","fault-proof/stage-one/bond-incentives.html#fault-proof-mainnet-incentives","fault-proof/stage-one/bond-incentives.html#authenticated-roles","fault-proof/stage-one/bond-incentives.html#base-fee-assumption","fault-proof/stage-one/bond-incentives.html#bond-scaling","fault-proof/stage-one/bond-incentives.html#required-bond-formula","fault-proof/stage-one/bond-incentives.html#other-incentives","fault-proof/stage-one/bond-incentives.html#delayedweth","fault-proof/stage-one/bridge-integration.html#bridge-integration","fault-proof/stage-one/bridge-integration.html#overview","fault-proof/stage-one/bridge-integration.html#legacy-semantics","fault-proof/stage-one/bridge-integration.html#fpac-optimismportal-mods-specification","fault-proof/stage-one/bridge-integration.html#roles---optimismportal","fault-proof/stage-one/bridge-integration.html#new-deployconfig-variables","fault-proof/stage-one/bridge-integration.html#data-structures","fault-proof/stage-one/bridge-integration.html#state-layout","fault-proof/stage-one/bridge-integration.html#provewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#finalizewithdrawaltransaction-modifications","fault-proof/stage-one/bridge-integration.html#air-gap","fault-proof/stage-one/bridge-integration.html#proxy-upgrade","fault-proof/stage-one/bridge-integration.html#permissioned-faultdisputegame","fault-proof/stage-one/bridge-integration.html#roles---permissioneddisputegame","fault-proof/stage-one/bridge-integration.html#modifications","protocol/precompiles.html#precompiles","protocol/precompiles.html#overview","protocol/precompiles.html#p256verify","protocol/predeploys.html#predeploys","protocol/predeploys.html#overview","protocol/predeploys.html#legacymessagepasser","protocol/predeploys.html#l2tol1messagepasser","protocol/predeploys.html#deployerwhitelist","protocol/predeploys.html#legacyerc20eth","protocol/predeploys.html#weth9","protocol/predeploys.html#l2crossdomainmessenger","protocol/predeploys.html#l2standardbridge","protocol/predeploys.html#l1blocknumber","protocol/predeploys.html#gaspriceoracle","protocol/predeploys.html#l1block","protocol/predeploys.html#proxyadmin","protocol/predeploys.html#sequencerfeevault","protocol/predeploys.html#optimismmintableerc20factory","protocol/predeploys.html#optimismmintableerc721factory","protocol/predeploys.html#basefeevault","protocol/predeploys.html#l1feevault","protocol/predeploys.html#schemaregistry","protocol/predeploys.html#eas","protocol/predeploys.html#beacon-block-root","protocol/preinstalls.html#preinstalls","protocol/preinstalls.html#overview","protocol/preinstalls.html#safe","protocol/preinstalls.html#safel2","protocol/preinstalls.html#multisend","protocol/preinstalls.html#multisendcallonly","protocol/preinstalls.html#safesingletonfactory","protocol/preinstalls.html#multicall3","protocol/preinstalls.html#create2deployer","protocol/preinstalls.html#createx","protocol/preinstalls.html#arachnids-deterministic-deployment-proxy","protocol/preinstalls.html#permit2","protocol/preinstalls.html#erc-4337-v060-entrypoint","protocol/preinstalls.html#erc-4337-v060-sendercreator","protocol/preinstalls.html#erc-4337-v070-entrypoint","protocol/preinstalls.html#erc-4337-v070-sendercreator","protocol/superchain-configuration.html#superchain-configuration","protocol/superchain-configuration.html#overview","protocol/superchain-configuration.html#configurable-values","protocol/superchain-configuration.html#configuration-data-flow","protocol/superchain-configuration.html#pausability","protocol/superchain-upgrades.html#superchain-upgrades","protocol/superchain-upgrades.html#overview","protocol/superchain-upgrades.html#protocol-version","protocol/superchain-upgrades.html#protocol-version-format","protocol/superchain-upgrades.html#protocol-version-exposure","protocol/superchain-upgrades.html#superchain-target","protocol/superchain-upgrades.html#superchain-version-signaling","protocol/superchain-upgrades.html#protocolversions-l1-contract","protocol/superchain-upgrades.html#activation-rules","protocol/superchain-upgrades.html#l2-block-number-based-activation-deprecated","protocol/superchain-upgrades.html#l2-block-timestamp-based-activation","protocol/superchain-upgrades.html#op-stack-protocol-versions","protocol/superchain-upgrades.html#post-bedrock-network-upgrades","protocol/superchain-upgrades.html#activation-timestamps","protocol/system-config.html#system-config","protocol/system-config.html#overview","protocol/system-config.html#system-config-contents-version-0","protocol/system-config.html#batcherhash-bytes32","protocol/system-config.html#scalars","protocol/system-config.html#gaslimit-uint64","protocol/system-config.html#unsafeblocksigner-address","protocol/system-config.html#writing-the-system-config","protocol/system-config.html#reading-the-system-config","protocol/configurability.html#op-stack-configurability","protocol/configurability.html#consensus-parameters","protocol/configurability.html#batch-inbox-address","protocol/configurability.html#batcher-hash","protocol/configurability.html#chain-id","protocol/configurability.html#proof-maturity-delay","protocol/configurability.html#dispute-game-finality","protocol/configurability.html#respected-game-type","protocol/configurability.html#fault-game-max-depth","protocol/configurability.html#fault-game-split-depth","protocol/configurability.html#max-game-clock-duration","protocol/configurability.html#game-clock-extension","protocol/configurability.html#bond-withdrawal-delay","protocol/configurability.html#minimum-large-preimage-proposal-size","protocol/configurability.html#large-preimage-proposal-challenge-period","protocol/configurability.html#fault-game-absolute-prestate","protocol/configurability.html#fault-game-genesis-block","protocol/configurability.html#fault-game-genesis-output-root","protocol/configurability.html#fee-scalar","protocol/configurability.html#gas-limit","protocol/configurability.html#genesis-state","protocol/configurability.html#l2-block-time","protocol/configurability.html#resource-config","protocol/configurability.html#sequencing-window-size","protocol/configurability.html#start-block","protocol/configurability.html#superchain-target","protocol/configurability.html#governance-token","protocol/configurability.html#resource-config-1","protocol/configurability.html#policy-parameters","protocol/configurability.html#data-availability-type","protocol/configurability.html#batch-submission-frequency","protocol/configurability.html#output-frequency","protocol/configurability.html#admin-roles","protocol/configurability.html#l1-proxy-admin","protocol/configurability.html#l1-proxyadmin-owner","protocol/configurability.html#l2-proxy-admin","protocol/configurability.html#l2-proxyadmin-owner","protocol/configurability.html#system-config-owner","protocol/configurability.html#service-roles","protocol/configurability.html#batch-submitter-address","protocol/configurability.html#challenger-address","protocol/configurability.html#guardian-address","protocol/configurability.html#proposer-address","protocol/configurability.html#sequencer-p2p--unsafe-head-signer","protocol/safe-extensions.html#safe-contract-extensions","protocol/safe-extensions.html#guardian-safe","protocol/safe-extensions.html#deputy-guardian-module","protocol/safe-extensions.html#deputy-guardian-module-security-properties","protocol/safe-extensions.html#security-council-liveness-checking-extensions","protocol/safe-extensions.html#the-liveness-guard","protocol/safe-extensions.html#the-liveness-module","protocol/safe-extensions.html#owner-removal-call-flow","protocol/safe-extensions.html#shutdown","protocol/safe-extensions.html#liveness-security-properties","protocol/safe-extensions.html#interdependency-between-the-liveness-guard-and-liveness-module","protocol/safe-extensions.html#operational-considerations","protocol/safe-extensions.html#manual-validation-of-new-owner-liveness","protocol/safe-extensions.html#deploying-the-liveness-checking-system","protocol/safe-extensions.html#modifying-the-liveness-checking-system","protocol/stage-1.html#stage-1-roles-and-requirements","protocol/stage-1.html#overview","protocol/stage-1.html#permissionless-fault-proofs","protocol/stage-1.html#roles-for-stage-1","protocol/stage-1.html#configuration-of-safes","protocol/stage-1.html#ownership-model-diagram","protocol/regolith/overview.html#regolith","protocol/regolith/overview.html#overview","protocol/canyon/overview.html#canyon","protocol/canyon/overview.html#execution-layer","protocol/canyon/overview.html#consensus-layer","protocol/delta/overview.html#delta","protocol/delta/overview.html#consensus-layer","protocol/delta/span-batches.html#span-batches","protocol/delta/span-batches.html#introduction","protocol/delta/span-batches.html#span-batch-format","protocol/delta/span-batches.html#span-batch-size-limits","protocol/delta/span-batches.html#future-batch-format-extension","protocol/delta/span-batches.html#span-batch-activation-rule","protocol/delta/span-batches.html#optimization-strategies","protocol/delta/span-batches.html#truncating-information-and-storing-only-necessary-data","protocol/delta/span-batches.html#tx_data_headers-removal-from-initial-specs","protocol/delta/span-batches.html#chain-id-removal-from-initial-specs","protocol/delta/span-batches.html#reorganization-of-constant-length-transaction-fields","protocol/delta/span-batches.html#rlp-encoding-for-only-variable-length-fields","protocol/delta/span-batches.html#store-y_parity-and-protected_bit-instead-of-v","protocol/delta/span-batches.html#adjust-txs-data-layout-for-better-compression","protocol/delta/span-batches.html#fee_recipients-encoding-scheme","protocol/delta/span-batches.html#how-derivation-works-with-span-batches","protocol/delta/span-batches.html#integration","protocol/delta/span-batches.html#channel-reader-batch-decoding","protocol/delta/span-batches.html#batch-queue","protocol/delta/span-batches.html#batcher","protocol/ecotone/overview.html#ecotone-network-upgrade","protocol/ecotone/overview.html#execution-layer","protocol/ecotone/overview.html#consensus-layer","protocol/ecotone/derivation.html#derivation","protocol/ecotone/derivation.html#ecotone-blob-retrieval","protocol/ecotone/derivation.html#blob-encoding","protocol/ecotone/l1-attributes.html#ecotone-l1-attributes","protocol/ecotone/l1-attributes.html#overview","protocol/ecotone/l1-attributes.html#l1-attributes-predeployed-contract","protocol/ecotone/l1-attributes.html#ecotone-l1block-upgrade","protocol/fjord/overview.html#fjord-network-upgrade","protocol/fjord/overview.html#execution-layer","protocol/fjord/overview.html#consensus-layer","protocol/fjord/exec-engine.html#l2-execution-engine","protocol/fjord/exec-engine.html#fees","protocol/fjord/exec-engine.html#l1-cost-fees-l1-fee-vault","protocol/fjord/exec-engine.html#l1-gas-usage-estimation","protocol/fjord/derivation.html#fjord-l2-chain-derivation-changes","protocol/fjord/derivation.html#protocol-parameter-changes","protocol/fjord/derivation.html#timestamp-activation","protocol/fjord/derivation.html#constant-maximum-sequencer-drift","protocol/fjord/derivation.html#rationale","protocol/fjord/derivation.html#security-considerations","protocol/fjord/derivation.html#increasing-max_rlp_bytes_per_channel-and-max_channel_bank_size","protocol/fjord/derivation.html#rationale-1","protocol/fjord/derivation.html#security-considerations-1","protocol/fjord/derivation.html#brotli-channel-compression","protocol/fjord/derivation.html#network-upgrade-automation-transactions","protocol/fjord/derivation.html#gaspriceoracle-deployment","protocol/fjord/derivation.html#gaspriceoracle-proxy-update","protocol/fjord/derivation.html#gaspriceoracle-enable-fjord","protocol/fjord/predeploys.html#predeploys","protocol/fjord/predeploys.html#gaspriceoracle","protocol/fjord/predeploys.html#l1-gas-usage-estimation","protocol/granite/overview.html#granite-network-upgrade","protocol/granite/overview.html#execution-layer","protocol/granite/overview.html#consensus-layer","protocol/granite/exec-engine.html#l2-execution-engine","protocol/granite/exec-engine.html#evm-changes","protocol/granite/exec-engine.html#bn256pairing-precompile-input-restriction","protocol/granite/derivation.html#granite-l2-chain-derivation-changes","protocol/granite/derivation.html#protocol-parameter-changes","protocol/granite/derivation.html#reduce-channel-timeout","protocol/holocene/overview.html#holocene-network-upgrade","protocol/holocene/overview.html#execution-layer","protocol/holocene/overview.html#consensus-layer","protocol/holocene/overview.html#smart-contracts","protocol/holocene/derivation.html#holocene-l2-chain-derivation-changes","protocol/holocene/derivation.html#holocene-derivation","protocol/holocene/derivation.html#summary","protocol/holocene/derivation.html#frame-queue","protocol/holocene/derivation.html#channel-bank","protocol/holocene/derivation.html#pruning","protocol/holocene/derivation.html#timeout","protocol/holocene/derivation.html#reading--frame-loading","protocol/holocene/derivation.html#span-batches","protocol/holocene/derivation.html#batch-queue","protocol/holocene/derivation.html#fast-channel-invalidation","protocol/holocene/derivation.html#engine-queue","protocol/holocene/derivation.html#attributes-builder","protocol/holocene/derivation.html#activation","protocol/holocene/derivation.html#rationale","protocol/holocene/derivation.html#strict-frame-and-batch-ordering","protocol/holocene/derivation.html#partial-span-batch-validity","protocol/holocene/derivation.html#fast-channel-invalidation-1","protocol/holocene/derivation.html#steady-block-derivation","protocol/holocene/derivation.html#less-defensive-protocol","protocol/holocene/derivation.html#security-and-implementation-considerations","protocol/holocene/derivation.html#reorgs","protocol/holocene/derivation.html#batcher-hardening","protocol/holocene/derivation.html#sync-start","protocol/holocene/exec-engine.html#l2-execution-engine","protocol/holocene/exec-engine.html#timestamp-activation","protocol/holocene/exec-engine.html#l2tol1messagepasser-storage-root-in-header","protocol/holocene/exec-engine.html#header-validity-rules","protocol/holocene/exec-engine.html#header-withdrawals-root","protocol/holocene/exec-engine.html#extended-payloadattributesv3","protocol/holocene/exec-engine.html#eip1559params-encoding","protocol/holocene/exec-engine.html#execution","protocol/holocene/exec-engine.html#rationale","protocol/holocene/exec-engine.html#eip1559params-in-header","protocol/holocene/exec-engine.html#header-validity-rules-1","protocol/holocene/exec-engine.html#encoding","protocol/holocene/exec-engine.html#rationale-1","protocol/holocene/predeploys.html#overview","protocol/holocene/predeploys.html#constants","protocol/holocene/predeploys.html#predeploys","protocol/holocene/predeploys.html#l1block","protocol/holocene/predeploys.html#feevault","protocol/holocene/predeploys.html#l2crossdomainmessenger","protocol/holocene/predeploys.html#l2erc721bridge","protocol/holocene/predeploys.html#l2standardbridge","protocol/holocene/predeploys.html#optimismmintableerc721factory","protocol/holocene/predeploys.html#security-considerations","protocol/holocene/predeploys.html#governancetoken","protocol/holocene/configurability.html#configurability","protocol/holocene/configurability.html#overview","protocol/holocene/configurability.html#constants","protocol/holocene/configurability.html#configtype","protocol/holocene/configurability.html#systemconfig","protocol/holocene/configurability.html#configupdate","protocol/holocene/configurability.html#initialization","protocol/holocene/configurability.html#modifying-eip-1559-parameters","protocol/holocene/configurability.html#interface","protocol/holocene/configurability.html#optimismportal","protocol/holocene/configurability.html#interface-1","governance/gov-token.html#governance-token","governance/gov-token.html#overview","governance/gov-token.html#token-minting","governance/gov-token.html#token-burning","governance/gov-token.html#voting-power","governance/gov-token.html#delegation","experimental/custom-gas-token.html#custom-gas-token","experimental/custom-gas-token.html#overview","experimental/custom-gas-token.html#constants","experimental/custom-gas-token.html#properties-of-a-gas-paying-token","experimental/custom-gas-token.html#automated-validation","experimental/custom-gas-token.html#configuring-the-gas-paying-token","experimental/custom-gas-token.html#contract-modifications","experimental/custom-gas-token.html#igastoken-interface","experimental/custom-gas-token.html#gas-token-aware","experimental/custom-gas-token.html#optimismportal","experimental/custom-gas-token.html#standardbridge","experimental/custom-gas-token.html#crossdomainmessenger","experimental/custom-gas-token.html#systemconfig","experimental/custom-gas-token.html#l1block","experimental/custom-gas-token.html#weth9","experimental/custom-gas-token.html#user-flow","experimental/custom-gas-token.html#when-eth-is-the-native-asset","experimental/custom-gas-token.html#when-an-erc20-token-is-the-native-asset","experimental/custom-gas-token.html#differences","experimental/custom-gas-token.html#upgrade","experimental/custom-gas-token.html#l1block-deployment","experimental/custom-gas-token.html#l2crossdomainmessenger-deployment","experimental/custom-gas-token.html#l2standardbridge-deployment","experimental/custom-gas-token.html#l1block-proxy-update","experimental/custom-gas-token.html#l2crossdomainmessenger-proxy-update","experimental/custom-gas-token.html#l2standardbridge-proxy-update","experimental/custom-gas-token.html#selection-of-ether_token_address","experimental/custom-gas-token.html#standard-config","experimental/custom-gas-token.html#fees","experimental/custom-gas-token.html#security-considerations","experimental/custom-gas-token.html#optimismportal-token-allowance","experimental/custom-gas-token.html#interoperability-support","experimental/custom-gas-token.html#wrapped-ether","experimental/alt-da.html#alt-da-mode","experimental/alt-da.html#overview","experimental/alt-da.html#input-commitment-submission","experimental/alt-da.html#da-server","experimental/alt-da.html#data-availability-challenge-contract","experimental/alt-da.html#parameters","experimental/alt-da.html#derivation","experimental/alt-da.html#fault-proof","experimental/alt-da.html#l2-input","experimental/alt-da.html#l1-challenge-status","experimental/alt-da.html#safety-and-finality","experimental/alt-da.html#security-considerations","interop/overview.html#interop","interop/overview.html#specifications","interop/dependency-set.html#the-dependency-set","interop/dependency-set.html#chain-id","interop/dependency-set.html#updating-the-dependency-set","interop/dependency-set.html#security-considerations","interop/dependency-set.html#layer-1-as-part-of-the-dependency-set","interop/messaging.html#messaging","interop/messaging.html#message","interop/messaging.html#message-payload","interop/messaging.html#message-identifier","interop/messaging.html#messaging-ends","interop/messaging.html#initiating-messages","interop/messaging.html#executing-messages","interop/messaging.html#messaging-invariants","interop/messaging.html#timestamp-invariant","interop/messaging.html#chainid-invariant","interop/messaging.html#message-expiry-invariant","interop/messaging.html#message-graph","interop/messaging.html#invalid-messages","interop/messaging.html#intra-block-messaging-cycles","interop/messaging.html#resolving-cross-chain-safety","interop/messaging.html#horizon-timestamp","interop/messaging.html#pruning-the-graph","interop/messaging.html#bounding-the-graph","interop/messaging.html#security-considerations","interop/messaging.html#cyclic-dependencies","interop/messaging.html#transitive-dependencies","interop/predeploys.html#predeploys","interop/predeploys.html#crossl2inbox","interop/predeploys.html#functions","interop/predeploys.html#interop-start-timestamp","interop/predeploys.html#executingmessage-event","interop/predeploys.html#reference-implementation","interop/predeploys.html#deposit-handling","interop/predeploys.html#identifier-getters","interop/predeploys.html#l2tol2crossdomainmessenger","interop/predeploys.html#relaymessage-invariants","interop/predeploys.html#sendexpire-invariants","interop/predeploys.html#relayexpire-invariants","interop/predeploys.html#message-versioning","interop/predeploys.html#no-native-support-for-cross-chain-ether-sends","interop/predeploys.html#interfaces","interop/predeploys.html#optimismsuperchainerc20factory","interop/predeploys.html#optimismsuperchainerc20","interop/predeploys.html#overview","interop/predeploys.html#functions-1","interop/predeploys.html#events","interop/predeploys.html#deployment-flow","interop/predeploys.html#beaconcontract","interop/predeploys.html#overview-1","interop/predeploys.html#l1block","interop/predeploys.html#static-configuration","interop/predeploys.html#dependency-set","interop/predeploys.html#deposit-context","interop/predeploys.html#isdeposit","interop/predeploys.html#optimismmintableerc20factory","interop/predeploys.html#optimismmintableerc20","interop/predeploys.html#updates","interop/predeploys.html#functions-2","interop/predeploys.html#events-1","interop/predeploys.html#l2standardbridge","interop/predeploys.html#updates-1","interop/predeploys.html#invariants","interop/predeploys.html#conversion-flow","interop/predeploys.html#superchainerc20bridge","interop/predeploys.html#overview-2","interop/predeploys.html#functions-3","interop/predeploys.html#events-2","interop/predeploys.html#diagram","interop/predeploys.html#invariants-1","interop/predeploys.html#security-considerations","interop/sequencer.html#sequencer","interop/sequencer.html#sequencer-policy","interop/sequencer.html#block-building","interop/sequencer.html#static-analysis","interop/sequencer.html#dependency-confirmations","interop/sequencer.html#sponsorship","interop/sequencer.html#security-considerations","interop/sequencer.html#cross-chain-message-latency","interop/verifier.html#verifier","interop/verifier.html#derivation-pipeline","interop/verifier.html#depositing-an-executing-message","interop/verifier.html#safety","interop/verifier.html#honest-verifier","interop/verifier.html#security-considerations","interop/verifier.html#forced-inclusion-of-cross-chain-messages","interop/verifier.html#reliance-on-history","interop/rollup-node-p2p.html#p2p-networking","interop/rollup-node-p2p.html#security-considerations","interop/fault-proof.html#fault-proof","interop/fault-proof.html#cascading-dependencies","interop/fault-proof.html#security-considerations","interop/upgrade.html#interop-network-upgrade","interop/upgrade.html#l1-attributes","interop/upgrade.html#l1-attributes-predeployed-contract","interop/upgrade.html#interop-l1block-upgrade","interop/upgrade.html#security-considerations","interop/token-bridging.html#token-bridging","interop/token-bridging.html#overview","interop/token-bridging.html#superchainerc20-standard","interop/token-bridging.html#properties","interop/token-bridging.html#interface","interop/token-bridging.html#superchainerc20bridge","interop/token-bridging.html#diagram","interop/token-bridging.html#implementation","interop/token-bridging.html#future-considerations","interop/token-bridging.html#cross-chain-transferfrom","interop/token-bridging.html#concatenated-action","interop/superchain-weth.html#superchain-weth","interop/superchain-weth.html#motivation-and-constraints","interop/superchain-weth.html#handling-native-assets-other-than-eth","interop/superchain-weth.html#minimizing-protocol-complexity","interop/superchain-weth.html#constants","interop/superchain-weth.html#superchainweth","interop/superchain-weth.html#invariants","interop/superchain-weth.html#ethliquidity","interop/superchain-weth.html#invariants-1","interop/derivation.html#derivation","interop/derivation.html#overview","interop/derivation.html#deposit-context","interop/derivation.html#security-considerations","interop/derivation.html#gas-considerations","interop/tx-pool.html#transaction-pool","interop/tx-pool.html#message-validation","interop/tx-pool.html#system-deposits-transaction-margin","interop/tx-pool.html#security-considerations","interop/tx-pool.html#mempool-denial-of-service","experimental/op-contracts-manager.html#op-contracts-manager","experimental/op-contracts-manager.html#deployment","experimental/op-contracts-manager.html#interface","experimental/op-contracts-manager.html#proxysol","experimental/op-contracts-manager.html#deploy","experimental/op-contracts-manager.html#getter-methods","experimental/op-contracts-manager.html#implementation","experimental/op-contracts-manager.html#batch-inbox-address","experimental/op-contracts-manager.html#contract-deployments","experimental/op-contracts-manager.html#security-considerations","experimental/op-contracts-manager.html#chain-id-source-of-truth","experimental/op-contracts-manager.html#chain-id-frontrunning","experimental/op-contracts-manager.html#chain-id-value","experimental/op-contracts-manager.html#proxy-admin-owner","experimental/op-contracts-manager.html#upgradeability-abi-changes","experimental/gov-token.html#governance-token","experimental/gov-token.html#overview","experimental/gov-token.html#hook-based-integration-with-governancedelegation","experimental/gov-token.html#token-minting","experimental/gov-token.html#token-burning","experimental/gov-token.html#voting-power","experimental/gov-token.html#delegation","glossary.html#glossary","glossary.html#general-terms","glossary.html#layer-1-l1","glossary.html#layer-2-l2","glossary.html#block","glossary.html#eoa","glossary.html#merkle-patricia-trie","glossary.html#chain-re-organization","glossary.html#predeployed-contract-predeploy","glossary.html#preinstalled-contract-preinstall","glossary.html#precompiled-contract-precompile","glossary.html#receipt","glossary.html#transaction-type","glossary.html#fork-choice-rule","glossary.html#priority-gas-auction","glossary.html#sequencing","glossary.html#sequencer","glossary.html#sequencing-window","glossary.html#sequencing-epoch","glossary.html#l1-origin","glossary.html#deposits","glossary.html#deposited-transaction","glossary.html#l1-attributes-deposited-transaction","glossary.html#user-deposited-transaction","glossary.html#depositing-call","glossary.html#depositing-transaction","glossary.html#depositor","glossary.html#deposited-transaction-type","glossary.html#deposit-contract","glossary.html#withdrawals","glossary.html#relayer","glossary.html#finalization-period","glossary.html#batch-submission","glossary.html#data-availability","glossary.html#data-availability-provider","glossary.html#sequencer-batch","glossary.html#channel","glossary.html#channel-frame","glossary.html#batcher","glossary.html#batcher-transaction","glossary.html#batch-submission-frequency","glossary.html#channel-timeout","glossary.html#l2-output-root-proposals","glossary.html#proposer","glossary.html#l2-chain-derivation","glossary.html#l2-derivation-inputs","glossary.html#system-configuration","glossary.html#payload-attributes","glossary.html#l2-genesis-block","glossary.html#l2-chain-inception","glossary.html#safe-l2-block","glossary.html#safe-l2-head","glossary.html#unsafe-l2-block","glossary.html#unsafe-l2-head","glossary.html#unsafe-block-consolidation","glossary.html#finalized-l2-head","glossary.html#other-l2-chain-concepts","glossary.html#address-aliasing","glossary.html#rollup-node","glossary.html#rollup-driver","glossary.html#l1-attributes-predeployed-contract","glossary.html#l2-output-root","glossary.html#l2-output-oracle-contract","glossary.html#validator","glossary.html#fault-proof","glossary.html#time-slot","glossary.html#block-time","glossary.html#unsafe-sync","glossary.html#execution-engine-concepts","glossary.html#execution-engine"],"index":{"documentStore":{"docInfo":{"0":{"body":7,"breadcrumbs":4,"title":3},"1":{"body":51,"breadcrumbs":2,"title":1},"10":{"body":17,"breadcrumbs":3,"title":2},"100":{"body":260,"breadcrumbs":7,"title":1},"101":{"body":81,"breadcrumbs":7,"title":1},"102":{"body":7,"breadcrumbs":7,"title":1},"103":{"body":30,"breadcrumbs":7,"title":1},"104":{"body":9,"breadcrumbs":7,"title":1},"105":{"body":36,"breadcrumbs":7,"title":1},"106":{"body":72,"breadcrumbs":7,"title":1},"107":{"body":99,"breadcrumbs":7,"title":1},"108":{"body":53,"breadcrumbs":7,"title":1},"109":{"body":99,"breadcrumbs":9,"title":3},"11":{"body":33,"breadcrumbs":2,"title":1},"110":{"body":47,"breadcrumbs":9,"title":3},"111":{"body":97,"breadcrumbs":10,"title":4},"112":{"body":80,"breadcrumbs":10,"title":4},"113":{"body":31,"breadcrumbs":8,"title":2},"114":{"body":20,"breadcrumbs":9,"title":3},"115":{"body":26,"breadcrumbs":7,"title":1},"116":{"body":26,"breadcrumbs":7,"title":1},"117":{"body":85,"breadcrumbs":7,"title":1},"118":{"body":13,"breadcrumbs":10,"title":4},"119":{"body":112,"breadcrumbs":7,"title":1},"12":{"body":30,"breadcrumbs":2,"title":1},"120":{"body":57,"breadcrumbs":9,"title":3},"121":{"body":61,"breadcrumbs":9,"title":3},"122":{"body":60,"breadcrumbs":13,"title":4},"123":{"body":143,"breadcrumbs":10,"title":1},"124":{"body":0,"breadcrumbs":11,"title":2},"125":{"body":69,"breadcrumbs":10,"title":1},"126":{"body":149,"breadcrumbs":10,"title":1},"127":{"body":576,"breadcrumbs":10,"title":1},"128":{"body":9,"breadcrumbs":11,"title":2},"129":{"body":5,"breadcrumbs":10,"title":1},"13":{"body":29,"breadcrumbs":2,"title":1},"130":{"body":4,"breadcrumbs":10,"title":1},"131":{"body":4,"breadcrumbs":10,"title":1},"132":{"body":71,"breadcrumbs":11,"title":2},"133":{"body":42,"breadcrumbs":11,"title":2},"134":{"body":233,"breadcrumbs":11,"title":2},"135":{"body":167,"breadcrumbs":11,"title":2},"136":{"body":255,"breadcrumbs":10,"title":1},"137":{"body":130,"breadcrumbs":11,"title":4},"138":{"body":420,"breadcrumbs":8,"title":1},"139":{"body":59,"breadcrumbs":10,"title":3},"14":{"body":84,"breadcrumbs":3,"title":2},"140":{"body":49,"breadcrumbs":9,"title":2},"141":{"body":0,"breadcrumbs":9,"title":2},"142":{"body":147,"breadcrumbs":11,"title":4},"143":{"body":478,"breadcrumbs":11,"title":4},"144":{"body":64,"breadcrumbs":10,"title":3},"145":{"body":115,"breadcrumbs":9,"title":2},"146":{"body":133,"breadcrumbs":9,"title":2},"147":{"body":120,"breadcrumbs":9,"title":2},"148":{"body":33,"breadcrumbs":8,"title":1},"149":{"body":143,"breadcrumbs":11,"title":4},"15":{"body":18,"breadcrumbs":2,"title":1},"150":{"body":47,"breadcrumbs":9,"title":2},"151":{"body":68,"breadcrumbs":9,"title":2},"152":{"body":20,"breadcrumbs":9,"title":2},"153":{"body":311,"breadcrumbs":9,"title":2},"154":{"body":19,"breadcrumbs":11,"title":4},"155":{"body":480,"breadcrumbs":9,"title":2},"156":{"body":57,"breadcrumbs":10,"title":3},"157":{"body":874,"breadcrumbs":9,"title":2},"158":{"body":581,"breadcrumbs":9,"title":2},"159":{"body":43,"breadcrumbs":10,"title":3},"16":{"body":103,"breadcrumbs":2,"title":1},"160":{"body":140,"breadcrumbs":10,"title":3},"161":{"body":700,"breadcrumbs":11,"title":4},"162":{"body":65,"breadcrumbs":11,"title":4},"163":{"body":3,"breadcrumbs":8,"title":2},"164":{"body":116,"breadcrumbs":7,"title":1},"165":{"body":114,"breadcrumbs":7,"title":2},"166":{"body":77,"breadcrumbs":6,"title":1},"167":{"body":52,"breadcrumbs":8,"title":3},"168":{"body":548,"breadcrumbs":9,"title":4},"169":{"body":51,"breadcrumbs":6,"title":1},"17":{"body":62,"breadcrumbs":2,"title":1},"170":{"body":215,"breadcrumbs":6,"title":1},"171":{"body":128,"breadcrumbs":8,"title":3},"172":{"body":55,"breadcrumbs":8,"title":3},"173":{"body":146,"breadcrumbs":6,"title":1},"174":{"body":252,"breadcrumbs":7,"title":2},"175":{"body":142,"breadcrumbs":6,"title":1},"176":{"body":190,"breadcrumbs":9,"title":4},"177":{"body":55,"breadcrumbs":7,"title":2},"178":{"body":104,"breadcrumbs":8,"title":3},"179":{"body":88,"breadcrumbs":10,"title":5},"18":{"body":0,"breadcrumbs":4,"title":3},"180":{"body":30,"breadcrumbs":14,"title":5},"181":{"body":75,"breadcrumbs":10,"title":1},"182":{"body":116,"breadcrumbs":10,"title":1},"183":{"body":51,"breadcrumbs":11,"title":2},"184":{"body":59,"breadcrumbs":10,"title":1},"185":{"body":82,"breadcrumbs":10,"title":1},"186":{"body":63,"breadcrumbs":11,"title":2},"187":{"body":165,"breadcrumbs":10,"title":1},"188":{"body":126,"breadcrumbs":10,"title":1},"189":{"body":26,"breadcrumbs":11,"title":2},"19":{"body":93,"breadcrumbs":4,"title":3},"190":{"body":22,"breadcrumbs":11,"title":2},"191":{"body":162,"breadcrumbs":12,"title":3},"192":{"body":68,"breadcrumbs":10,"title":1},"193":{"body":0,"breadcrumbs":11,"title":2},"194":{"body":147,"breadcrumbs":11,"title":2},"195":{"body":121,"breadcrumbs":11,"title":2},"196":{"body":19,"breadcrumbs":11,"title":3},"197":{"body":8,"breadcrumbs":14,"title":3},"198":{"body":74,"breadcrumbs":12,"title":1},"199":{"body":179,"breadcrumbs":12,"title":1},"2":{"body":28,"breadcrumbs":3,"title":2},"20":{"body":141,"breadcrumbs":2,"title":1},"200":{"body":614,"breadcrumbs":13,"title":2},"201":{"body":348,"breadcrumbs":13,"title":2},"202":{"body":52,"breadcrumbs":14,"title":3},"203":{"body":79,"breadcrumbs":12,"title":1},"204":{"body":0,"breadcrumbs":12,"title":1},"205":{"body":44,"breadcrumbs":14,"title":3},"206":{"body":31,"breadcrumbs":12,"title":1},"207":{"body":25,"breadcrumbs":13,"title":2},"208":{"body":64,"breadcrumbs":12,"title":1},"209":{"body":78,"breadcrumbs":13,"title":2},"21":{"body":19,"breadcrumbs":3,"title":2},"210":{"body":29,"breadcrumbs":14,"title":3},"211":{"body":34,"breadcrumbs":12,"title":1},"212":{"body":80,"breadcrumbs":12,"title":1},"213":{"body":68,"breadcrumbs":13,"title":2},"214":{"body":112,"breadcrumbs":12,"title":1},"215":{"body":12,"breadcrumbs":12,"title":1},"216":{"body":15,"breadcrumbs":12,"title":1},"217":{"body":92,"breadcrumbs":13,"title":2},"218":{"body":22,"breadcrumbs":14,"title":3},"219":{"body":32,"breadcrumbs":12,"title":1},"22":{"body":72,"breadcrumbs":5,"title":2},"220":{"body":216,"breadcrumbs":12,"title":1},"221":{"body":110,"breadcrumbs":15,"title":4},"222":{"body":122,"breadcrumbs":12,"title":1},"223":{"body":123,"breadcrumbs":13,"title":2},"224":{"body":428,"breadcrumbs":13,"title":2},"225":{"body":58,"breadcrumbs":13,"title":2},"226":{"body":128,"breadcrumbs":13,"title":2},"227":{"body":229,"breadcrumbs":12,"title":1},"228":{"body":87,"breadcrumbs":12,"title":1},"229":{"body":12,"breadcrumbs":18,"title":5},"23":{"body":98,"breadcrumbs":6,"title":3},"230":{"body":90,"breadcrumbs":14,"title":1},"231":{"body":39,"breadcrumbs":14,"title":1},"232":{"body":93,"breadcrumbs":17,"title":4},"233":{"body":52,"breadcrumbs":14,"title":1},"234":{"body":65,"breadcrumbs":14,"title":1},"235":{"body":11,"breadcrumbs":14,"title":1},"236":{"body":64,"breadcrumbs":14,"title":1},"237":{"body":31,"breadcrumbs":15,"title":2},"238":{"body":65,"breadcrumbs":14,"title":1},"239":{"body":60,"breadcrumbs":14,"title":1},"24":{"body":0,"breadcrumbs":5,"title":2},"240":{"body":42,"breadcrumbs":15,"title":2},"241":{"body":53,"breadcrumbs":16,"title":3},"242":{"body":15,"breadcrumbs":17,"title":4},"243":{"body":27,"breadcrumbs":15,"title":2},"244":{"body":37,"breadcrumbs":16,"title":3},"245":{"body":90,"breadcrumbs":15,"title":2},"246":{"body":23,"breadcrumbs":16,"title":3},"247":{"body":31,"breadcrumbs":14,"title":1},"248":{"body":367,"breadcrumbs":14,"title":1},"249":{"body":54,"breadcrumbs":12,"title":2},"25":{"body":394,"breadcrumbs":7,"title":4},"250":{"body":27,"breadcrumbs":11,"title":1},"251":{"body":151,"breadcrumbs":12,"title":2},"252":{"body":0,"breadcrumbs":14,"title":4},"253":{"body":10,"breadcrumbs":12,"title":2},"254":{"body":39,"breadcrumbs":13,"title":3},"255":{"body":42,"breadcrumbs":12,"title":2},"256":{"body":96,"breadcrumbs":12,"title":2},"257":{"body":168,"breadcrumbs":12,"title":2},"258":{"body":122,"breadcrumbs":12,"title":2},"259":{"body":168,"breadcrumbs":12,"title":2},"26":{"body":251,"breadcrumbs":7,"title":4},"260":{"body":23,"breadcrumbs":12,"title":2},"261":{"body":43,"breadcrumbs":12,"title":2},"262":{"body":12,"breadcrumbs":12,"title":2},"263":{"body":43,"breadcrumbs":11,"title":1},"264":{"body":4,"breadcrumbs":5,"title":1},"265":{"body":61,"breadcrumbs":5,"title":1},"266":{"body":35,"breadcrumbs":5,"title":1},"267":{"body":24,"breadcrumbs":5,"title":1},"268":{"body":168,"breadcrumbs":5,"title":1},"269":{"body":71,"breadcrumbs":5,"title":1},"27":{"body":70,"breadcrumbs":6,"title":3},"270":{"body":33,"breadcrumbs":5,"title":1},"271":{"body":48,"breadcrumbs":5,"title":1},"272":{"body":41,"breadcrumbs":5,"title":1},"273":{"body":19,"breadcrumbs":5,"title":1},"274":{"body":59,"breadcrumbs":5,"title":1},"275":{"body":84,"breadcrumbs":5,"title":1},"276":{"body":30,"breadcrumbs":5,"title":1},"277":{"body":141,"breadcrumbs":5,"title":1},"278":{"body":16,"breadcrumbs":5,"title":1},"279":{"body":18,"breadcrumbs":5,"title":1},"28":{"body":142,"breadcrumbs":6,"title":3},"280":{"body":29,"breadcrumbs":5,"title":1},"281":{"body":43,"breadcrumbs":5,"title":1},"282":{"body":14,"breadcrumbs":5,"title":1},"283":{"body":25,"breadcrumbs":5,"title":1},"284":{"body":21,"breadcrumbs":5,"title":1},"285":{"body":13,"breadcrumbs":5,"title":1},"286":{"body":10,"breadcrumbs":5,"title":1},"287":{"body":18,"breadcrumbs":7,"title":3},"288":{"body":32,"breadcrumbs":5,"title":1},"289":{"body":96,"breadcrumbs":5,"title":1},"29":{"body":56,"breadcrumbs":5,"title":2},"290":{"body":18,"breadcrumbs":5,"title":1},"291":{"body":16,"breadcrumbs":5,"title":1},"292":{"body":8,"breadcrumbs":5,"title":1},"293":{"body":9,"breadcrumbs":5,"title":1},"294":{"body":51,"breadcrumbs":5,"title":1},"295":{"body":24,"breadcrumbs":5,"title":1},"296":{"body":127,"breadcrumbs":5,"title":1},"297":{"body":26,"breadcrumbs":5,"title":1},"298":{"body":87,"breadcrumbs":8,"title":4},"299":{"body":22,"breadcrumbs":5,"title":1},"3":{"body":17,"breadcrumbs":3,"title":2},"30":{"body":0,"breadcrumbs":6,"title":3},"300":{"body":12,"breadcrumbs":8,"title":4},"301":{"body":14,"breadcrumbs":8,"title":4},"302":{"body":12,"breadcrumbs":8,"title":4},"303":{"body":14,"breadcrumbs":8,"title":4},"304":{"body":13,"breadcrumbs":8,"title":2},"305":{"body":14,"breadcrumbs":7,"title":1},"306":{"body":25,"breadcrumbs":8,"title":2},"307":{"body":29,"breadcrumbs":9,"title":3},"308":{"body":70,"breadcrumbs":7,"title":1},"309":{"body":52,"breadcrumbs":8,"title":2},"31":{"body":69,"breadcrumbs":4,"title":1},"310":{"body":57,"breadcrumbs":7,"title":1},"311":{"body":123,"breadcrumbs":8,"title":2},"312":{"body":326,"breadcrumbs":9,"title":3},"313":{"body":36,"breadcrumbs":9,"title":3},"314":{"body":42,"breadcrumbs":8,"title":2},"315":{"body":88,"breadcrumbs":9,"title":3},"316":{"body":47,"breadcrumbs":9,"title":3},"317":{"body":58,"breadcrumbs":8,"title":2},"318":{"body":72,"breadcrumbs":12,"title":6},"319":{"body":100,"breadcrumbs":11,"title":5},"32":{"body":326,"breadcrumbs":5,"title":2},"320":{"body":130,"breadcrumbs":10,"title":4},"321":{"body":0,"breadcrumbs":10,"title":4},"322":{"body":49,"breadcrumbs":8,"title":2},"323":{"body":31,"breadcrumbs":7,"title":2},"324":{"body":19,"breadcrumbs":6,"title":1},"325":{"body":8,"breadcrumbs":10,"title":5},"326":{"body":43,"breadcrumbs":7,"title":2},"327":{"body":287,"breadcrumbs":6,"title":1},"328":{"body":51,"breadcrumbs":7,"title":2},"329":{"body":51,"breadcrumbs":7,"title":2},"33":{"body":139,"breadcrumbs":5,"title":2},"330":{"body":33,"breadcrumbs":8,"title":3},"331":{"body":219,"breadcrumbs":8,"title":3},"332":{"body":256,"breadcrumbs":7,"title":3},"333":{"body":0,"breadcrumbs":6,"title":2},"334":{"body":26,"breadcrumbs":7,"title":3},"335":{"body":22,"breadcrumbs":6,"title":2},"336":{"body":29,"breadcrumbs":6,"title":2},"337":{"body":41,"breadcrumbs":7,"title":3},"338":{"body":34,"breadcrumbs":7,"title":3},"339":{"body":31,"breadcrumbs":7,"title":3},"34":{"body":6,"breadcrumbs":6,"title":2},"340":{"body":25,"breadcrumbs":8,"title":4},"341":{"body":32,"breadcrumbs":8,"title":4},"342":{"body":26,"breadcrumbs":8,"title":4},"343":{"body":27,"breadcrumbs":7,"title":3},"344":{"body":27,"breadcrumbs":7,"title":3},"345":{"body":36,"breadcrumbs":9,"title":5},"346":{"body":28,"breadcrumbs":9,"title":5},"347":{"body":34,"breadcrumbs":8,"title":4},"348":{"body":30,"breadcrumbs":8,"title":4},"349":{"body":18,"breadcrumbs":9,"title":5},"35":{"body":186,"breadcrumbs":5,"title":1},"350":{"body":20,"breadcrumbs":6,"title":2},"351":{"body":31,"breadcrumbs":6,"title":2},"352":{"body":29,"breadcrumbs":6,"title":2},"353":{"body":24,"breadcrumbs":7,"title":3},"354":{"body":26,"breadcrumbs":6,"title":2},"355":{"body":48,"breadcrumbs":7,"title":3},"356":{"body":19,"breadcrumbs":6,"title":2},"357":{"body":35,"breadcrumbs":6,"title":2},"358":{"body":23,"breadcrumbs":6,"title":2},"359":{"body":18,"breadcrumbs":6,"title":2},"36":{"body":24,"breadcrumbs":6,"title":2},"360":{"body":0,"breadcrumbs":6,"title":2},"361":{"body":34,"breadcrumbs":7,"title":3},"362":{"body":48,"breadcrumbs":7,"title":3},"363":{"body":39,"breadcrumbs":6,"title":2},"364":{"body":0,"breadcrumbs":6,"title":2},"365":{"body":52,"breadcrumbs":7,"title":3},"366":{"body":20,"breadcrumbs":7,"title":3},"367":{"body":31,"breadcrumbs":7,"title":3},"368":{"body":37,"breadcrumbs":7,"title":3},"369":{"body":83,"breadcrumbs":7,"title":3},"37":{"body":8,"breadcrumbs":5,"title":1},"370":{"body":0,"breadcrumbs":6,"title":2},"371":{"body":15,"breadcrumbs":7,"title":3},"372":{"body":33,"breadcrumbs":6,"title":2},"373":{"body":37,"breadcrumbs":6,"title":2},"374":{"body":39,"breadcrumbs":6,"title":2},"375":{"body":28,"breadcrumbs":9,"title":5},"376":{"body":128,"breadcrumbs":8,"title":3},"377":{"body":6,"breadcrumbs":7,"title":2},"378":{"body":178,"breadcrumbs":8,"title":3},"379":{"body":58,"breadcrumbs":10,"title":5},"38":{"body":17,"breadcrumbs":8,"title":3},"380":{"body":52,"breadcrumbs":10,"title":5},"381":{"body":94,"breadcrumbs":7,"title":2},"382":{"body":52,"breadcrumbs":7,"title":2},"383":{"body":51,"breadcrumbs":9,"title":4},"384":{"body":23,"breadcrumbs":6,"title":1},"385":{"body":126,"breadcrumbs":8,"title":3},"386":{"body":29,"breadcrumbs":11,"title":6},"387":{"body":0,"breadcrumbs":7,"title":2},"388":{"body":22,"breadcrumbs":10,"title":5},"389":{"body":62,"breadcrumbs":9,"title":4},"39":{"body":186,"breadcrumbs":6,"title":1},"390":{"body":76,"breadcrumbs":9,"title":4},"391":{"body":14,"breadcrumbs":13,"title":4},"392":{"body":20,"breadcrumbs":10,"title":1},"393":{"body":7,"breadcrumbs":12,"title":3},"394":{"body":82,"breadcrumbs":12,"title":3},"395":{"body":177,"breadcrumbs":11,"title":2},"396":{"body":134,"breadcrumbs":12,"title":3},"397":{"body":3,"breadcrumbs":7,"title":1},"398":{"body":158,"breadcrumbs":7,"title":1},"399":{"body":40,"breadcrumbs":7,"title":1},"4":{"body":29,"breadcrumbs":2,"title":1},"40":{"body":75,"breadcrumbs":7,"title":2},"400":{"body":51,"breadcrumbs":8,"title":2},"401":{"body":3,"breadcrumbs":8,"title":2},"402":{"body":16,"breadcrumbs":7,"title":1},"403":{"body":9,"breadcrumbs":8,"title":2},"404":{"body":70,"breadcrumbs":10,"title":2},"405":{"body":150,"breadcrumbs":9,"title":1},"406":{"body":314,"breadcrumbs":11,"title":3},"407":{"body":38,"breadcrumbs":12,"title":4},"408":{"body":74,"breadcrumbs":12,"title":4},"409":{"body":41,"breadcrumbs":12,"title":4},"41":{"body":13,"breadcrumbs":6,"title":1},"410":{"body":0,"breadcrumbs":10,"title":2},"411":{"body":27,"breadcrumbs":13,"title":5},"412":{"body":19,"breadcrumbs":12,"title":4},"413":{"body":20,"breadcrumbs":13,"title":5},"414":{"body":24,"breadcrumbs":13,"title":5},"415":{"body":44,"breadcrumbs":13,"title":5},"416":{"body":64,"breadcrumbs":13,"title":5},"417":{"body":32,"breadcrumbs":14,"title":6},"418":{"body":75,"breadcrumbs":11,"title":3},"419":{"body":142,"breadcrumbs":12,"title":4},"42":{"body":36,"breadcrumbs":7,"title":2},"420":{"body":0,"breadcrumbs":9,"title":1},"421":{"body":18,"breadcrumbs":12,"title":4},"422":{"body":482,"breadcrumbs":10,"title":2},"423":{"body":101,"breadcrumbs":9,"title":1},"424":{"body":18,"breadcrumbs":9,"title":3},"425":{"body":80,"breadcrumbs":8,"title":2},"426":{"body":30,"breadcrumbs":8,"title":2},"427":{"body":7,"breadcrumbs":8,"title":1},"428":{"body":110,"breadcrumbs":10,"title":3},"429":{"body":279,"breadcrumbs":9,"title":2},"43":{"body":6,"breadcrumbs":8,"title":3},"430":{"body":10,"breadcrumbs":11,"title":3},"431":{"body":203,"breadcrumbs":9,"title":1},"432":{"body":116,"breadcrumbs":12,"title":4},"433":{"body":111,"breadcrumbs":11,"title":3},"434":{"body":6,"breadcrumbs":9,"title":3},"435":{"body":22,"breadcrumbs":8,"title":2},"436":{"body":16,"breadcrumbs":8,"title":2},"437":{"body":27,"breadcrumbs":11,"title":3},"438":{"body":0,"breadcrumbs":9,"title":1},"439":{"body":266,"breadcrumbs":14,"title":6},"44":{"body":8,"breadcrumbs":8,"title":3},"440":{"body":24,"breadcrumbs":12,"title":4},"441":{"body":35,"breadcrumbs":12,"title":5},"442":{"body":35,"breadcrumbs":10,"title":3},"443":{"body":51,"breadcrumbs":9,"title":2},"444":{"body":34,"breadcrumbs":11,"title":4},"445":{"body":53,"breadcrumbs":8,"title":1},"446":{"body":66,"breadcrumbs":9,"title":2},"447":{"body":57,"breadcrumbs":10,"title":3},"448":{"body":110,"breadcrumbs":8,"title":1},"449":{"body":115,"breadcrumbs":9,"title":2},"45":{"body":45,"breadcrumbs":8,"title":3},"450":{"body":75,"breadcrumbs":10,"title":3},"451":{"body":43,"breadcrumbs":11,"title":4},"452":{"body":106,"breadcrumbs":9,"title":2},"453":{"body":75,"breadcrumbs":10,"title":3},"454":{"body":66,"breadcrumbs":10,"title":3},"455":{"body":7,"breadcrumbs":8,"title":1},"456":{"body":130,"breadcrumbs":8,"title":1},"457":{"body":91,"breadcrumbs":11,"title":4},"458":{"body":6,"breadcrumbs":9,"title":3},"459":{"body":5,"breadcrumbs":8,"title":2},"46":{"body":64,"breadcrumbs":6,"title":1},"460":{"body":4,"breadcrumbs":8,"title":2},"461":{"body":8,"breadcrumbs":11,"title":3},"462":{"body":0,"breadcrumbs":10,"title":2},"463":{"body":25,"breadcrumbs":12,"title":4},"464":{"body":8,"breadcrumbs":12,"title":5},"465":{"body":20,"breadcrumbs":10,"title":3},"466":{"body":18,"breadcrumbs":10,"title":3},"467":{"body":12,"breadcrumbs":9,"title":3},"468":{"body":4,"breadcrumbs":8,"title":2},"469":{"body":2,"breadcrumbs":8,"title":2},"47":{"body":40,"breadcrumbs":6,"title":1},"470":{"body":2,"breadcrumbs":8,"title":2},"471":{"body":52,"breadcrumbs":12,"title":5},"472":{"body":0,"breadcrumbs":9,"title":2},"473":{"body":114,"breadcrumbs":8,"title":1},"474":{"body":174,"breadcrumbs":9,"title":2},"475":{"body":13,"breadcrumbs":9,"title":2},"476":{"body":32,"breadcrumbs":8,"title":1},"477":{"body":6,"breadcrumbs":8,"title":1},"478":{"body":77,"breadcrumbs":10,"title":3},"479":{"body":167,"breadcrumbs":9,"title":2},"48":{"body":205,"breadcrumbs":8,"title":3},"480":{"body":83,"breadcrumbs":9,"title":2},"481":{"body":39,"breadcrumbs":10,"title":3},"482":{"body":40,"breadcrumbs":9,"title":2},"483":{"body":72,"breadcrumbs":9,"title":2},"484":{"body":102,"breadcrumbs":8,"title":1},"485":{"body":0,"breadcrumbs":8,"title":1},"486":{"body":65,"breadcrumbs":11,"title":4},"487":{"body":59,"breadcrumbs":11,"title":4},"488":{"body":38,"breadcrumbs":10,"title":3},"489":{"body":54,"breadcrumbs":10,"title":3},"49":{"body":114,"breadcrumbs":8,"title":3},"490":{"body":70,"breadcrumbs":10,"title":3},"491":{"body":0,"breadcrumbs":10,"title":3},"492":{"body":85,"breadcrumbs":8,"title":1},"493":{"body":186,"breadcrumbs":9,"title":2},"494":{"body":180,"breadcrumbs":9,"title":2},"495":{"body":34,"breadcrumbs":11,"title":3},"496":{"body":15,"breadcrumbs":10,"title":2},"497":{"body":30,"breadcrumbs":12,"title":4},"498":{"body":40,"breadcrumbs":11,"title":3},"499":{"body":155,"breadcrumbs":11,"title":3},"5":{"body":40,"breadcrumbs":2,"title":1},"50":{"body":57,"breadcrumbs":8,"title":3},"500":{"body":33,"breadcrumbs":10,"title":2},"501":{"body":16,"breadcrumbs":10,"title":2},"502":{"body":45,"breadcrumbs":9,"title":1},"503":{"body":31,"breadcrumbs":9,"title":1},"504":{"body":13,"breadcrumbs":10,"title":2},"505":{"body":23,"breadcrumbs":11,"title":3},"506":{"body":6,"breadcrumbs":9,"title":1},"507":{"body":53,"breadcrumbs":9,"title":1},"508":{"body":53,"breadcrumbs":8,"title":1},"509":{"body":89,"breadcrumbs":8,"title":1},"51":{"body":24,"breadcrumbs":9,"title":4},"510":{"body":65,"breadcrumbs":8,"title":1},"511":{"body":149,"breadcrumbs":8,"title":1},"512":{"body":37,"breadcrumbs":8,"title":1},"513":{"body":11,"breadcrumbs":8,"title":1},"514":{"body":11,"breadcrumbs":8,"title":1},"515":{"body":11,"breadcrumbs":8,"title":1},"516":{"body":11,"breadcrumbs":8,"title":1},"517":{"body":0,"breadcrumbs":9,"title":2},"518":{"body":9,"breadcrumbs":8,"title":1},"519":{"body":28,"breadcrumbs":8,"title":1},"52":{"body":370,"breadcrumbs":6,"title":1},"520":{"body":7,"breadcrumbs":8,"title":1},"521":{"body":0,"breadcrumbs":8,"title":1},"522":{"body":58,"breadcrumbs":8,"title":1},"523":{"body":0,"breadcrumbs":8,"title":1},"524":{"body":56,"breadcrumbs":8,"title":1},"525":{"body":28,"breadcrumbs":8,"title":1},"526":{"body":15,"breadcrumbs":11,"title":4},"527":{"body":84,"breadcrumbs":8,"title":1},"528":{"body":7,"breadcrumbs":8,"title":1},"529":{"body":53,"breadcrumbs":8,"title":1},"53":{"body":146,"breadcrumbs":7,"title":2},"530":{"body":15,"breadcrumbs":5,"title":2},"531":{"body":49,"breadcrumbs":4,"title":1},"532":{"body":26,"breadcrumbs":5,"title":2},"533":{"body":25,"breadcrumbs":5,"title":2},"534":{"body":94,"breadcrumbs":5,"title":2},"535":{"body":37,"breadcrumbs":4,"title":1},"536":{"body":73,"breadcrumbs":7,"title":3},"537":{"body":83,"breadcrumbs":5,"title":1},"538":{"body":50,"breadcrumbs":5,"title":1},"539":{"body":77,"breadcrumbs":8,"title":4},"54":{"body":70,"breadcrumbs":9,"title":4},"540":{"body":50,"breadcrumbs":6,"title":2},"541":{"body":146,"breadcrumbs":8,"title":4},"542":{"body":0,"breadcrumbs":6,"title":2},"543":{"body":80,"breadcrumbs":6,"title":2},"544":{"body":20,"breadcrumbs":7,"title":3},"545":{"body":188,"breadcrumbs":5,"title":1},"546":{"body":65,"breadcrumbs":5,"title":1},"547":{"body":90,"breadcrumbs":5,"title":1},"548":{"body":85,"breadcrumbs":5,"title":1},"549":{"body":54,"breadcrumbs":5,"title":1},"55":{"body":25,"breadcrumbs":10,"title":5},"550":{"body":23,"breadcrumbs":5,"title":1},"551":{"body":39,"breadcrumbs":6,"title":2},"552":{"body":72,"breadcrumbs":7,"title":3},"553":{"body":86,"breadcrumbs":8,"title":4},"554":{"body":26,"breadcrumbs":5,"title":1},"555":{"body":146,"breadcrumbs":5,"title":1},"556":{"body":12,"breadcrumbs":6,"title":2},"557":{"body":12,"breadcrumbs":6,"title":2},"558":{"body":12,"breadcrumbs":6,"title":2},"559":{"body":12,"breadcrumbs":7,"title":3},"56":{"body":17,"breadcrumbs":8,"title":3},"560":{"body":12,"breadcrumbs":7,"title":3},"561":{"body":12,"breadcrumbs":7,"title":3},"562":{"body":17,"breadcrumbs":6,"title":2},"563":{"body":16,"breadcrumbs":6,"title":2},"564":{"body":47,"breadcrumbs":5,"title":1},"565":{"body":0,"breadcrumbs":6,"title":2},"566":{"body":25,"breadcrumbs":7,"title":3},"567":{"body":37,"breadcrumbs":6,"title":2},"568":{"body":17,"breadcrumbs":6,"title":2},"569":{"body":48,"breadcrumbs":6,"title":3},"57":{"body":19,"breadcrumbs":9,"title":4},"570":{"body":73,"breadcrumbs":4,"title":1},"571":{"body":194,"breadcrumbs":6,"title":3},"572":{"body":113,"breadcrumbs":5,"title":2},"573":{"body":0,"breadcrumbs":7,"title":4},"574":{"body":356,"breadcrumbs":4,"title":1},"575":{"body":393,"breadcrumbs":4,"title":1},"576":{"body":21,"breadcrumbs":5,"title":2},"577":{"body":7,"breadcrumbs":6,"title":3},"578":{"body":9,"breadcrumbs":8,"title":5},"579":{"body":125,"breadcrumbs":5,"title":2},"58":{"body":134,"breadcrumbs":9,"title":4},"580":{"body":63,"breadcrumbs":5,"title":2},"581":{"body":165,"breadcrumbs":3,"title":1},"582":{"body":78,"breadcrumbs":3,"title":1},"583":{"body":142,"breadcrumbs":6,"title":2},"584":{"body":69,"breadcrumbs":6,"title":2},"585":{"body":45,"breadcrumbs":7,"title":3},"586":{"body":0,"breadcrumbs":6,"title":2},"587":{"body":46,"breadcrumbs":9,"title":5},"588":{"body":50,"breadcrumbs":4,"title":1},"589":{"body":6,"breadcrumbs":4,"title":1},"59":{"body":92,"breadcrumbs":8,"title":3},"590":{"body":37,"breadcrumbs":5,"title":2},"591":{"body":121,"breadcrumbs":5,"title":2},"592":{"body":0,"breadcrumbs":5,"title":2},"593":{"body":43,"breadcrumbs":5,"title":2},"594":{"body":77,"breadcrumbs":5,"title":2},"595":{"body":41,"breadcrumbs":5,"title":2},"596":{"body":30,"breadcrumbs":5,"title":2},"597":{"body":21,"breadcrumbs":5,"title":2},"598":{"body":59,"breadcrumbs":6,"title":3},"599":{"body":25,"breadcrumbs":5,"title":2},"6":{"body":0,"breadcrumbs":2,"title":1},"60":{"body":121,"breadcrumbs":7,"title":2},"600":{"body":84,"breadcrumbs":5,"title":2},"601":{"body":28,"breadcrumbs":7,"title":4},"602":{"body":64,"breadcrumbs":7,"title":4},"603":{"body":15,"breadcrumbs":5,"title":2},"604":{"body":62,"breadcrumbs":5,"title":2},"605":{"body":67,"breadcrumbs":5,"title":2},"606":{"body":0,"breadcrumbs":5,"title":2},"607":{"body":27,"breadcrumbs":5,"title":2},"608":{"body":20,"breadcrumbs":5,"title":2},"609":{"body":118,"breadcrumbs":4,"title":1},"61":{"body":35,"breadcrumbs":6,"title":1},"610":{"body":25,"breadcrumbs":4,"title":1},"611":{"body":141,"breadcrumbs":4,"title":1},"612":{"body":67,"breadcrumbs":6,"title":3},"613":{"body":50,"breadcrumbs":5,"title":2},"614":{"body":175,"breadcrumbs":5,"title":2},"615":{"body":31,"breadcrumbs":5,"title":2},"616":{"body":11,"breadcrumbs":5,"title":2},"617":{"body":45,"breadcrumbs":4,"title":1},"618":{"body":9,"breadcrumbs":5,"title":2},"619":{"body":21,"breadcrumbs":5,"title":2},"62":{"body":132,"breadcrumbs":6,"title":1},"620":{"body":20,"breadcrumbs":5,"title":2},"621":{"body":17,"breadcrumbs":5,"title":2},"622":{"body":26,"breadcrumbs":9,"title":6},"623":{"body":464,"breadcrumbs":4,"title":1},"624":{"body":4,"breadcrumbs":4,"title":1},"625":{"body":31,"breadcrumbs":4,"title":1},"626":{"body":71,"breadcrumbs":4,"title":1},"627":{"body":85,"breadcrumbs":4,"title":1},"628":{"body":25,"breadcrumbs":4,"title":1},"629":{"body":49,"breadcrumbs":5,"title":2},"63":{"body":8,"breadcrumbs":7,"title":2},"630":{"body":4,"breadcrumbs":4,"title":1},"631":{"body":25,"breadcrumbs":4,"title":1},"632":{"body":6,"breadcrumbs":4,"title":1},"633":{"body":108,"breadcrumbs":5,"title":2},"634":{"body":113,"breadcrumbs":5,"title":2},"635":{"body":17,"breadcrumbs":5,"title":2},"636":{"body":34,"breadcrumbs":4,"title":1},"637":{"body":4,"breadcrumbs":4,"title":1},"638":{"body":34,"breadcrumbs":4,"title":1},"639":{"body":19,"breadcrumbs":4,"title":1},"64":{"body":17,"breadcrumbs":6,"title":1},"640":{"body":128,"breadcrumbs":4,"title":1},"641":{"body":34,"breadcrumbs":4,"title":1},"642":{"body":4,"breadcrumbs":4,"title":1},"643":{"body":110,"breadcrumbs":4,"title":1},"644":{"body":57,"breadcrumbs":4,"title":1},"645":{"body":53,"breadcrumbs":5,"title":2},"646":{"body":4,"breadcrumbs":4,"title":1},"647":{"body":19,"breadcrumbs":4,"title":1},"648":{"body":111,"breadcrumbs":4,"title":1},"649":{"body":40,"breadcrumbs":4,"title":1},"65":{"body":133,"breadcrumbs":6,"title":1},"650":{"body":83,"breadcrumbs":4,"title":1},"651":{"body":209,"breadcrumbs":4,"title":1},"652":{"body":1,"breadcrumbs":5,"title":2},"653":{"body":29,"breadcrumbs":4,"title":1},"654":{"body":39,"breadcrumbs":5,"title":2},"655":{"body":28,"breadcrumbs":5,"title":2},"656":{"body":21,"breadcrumbs":5,"title":2},"657":{"body":336,"breadcrumbs":5,"title":2},"658":{"body":25,"breadcrumbs":4,"title":1},"659":{"body":0,"breadcrumbs":5,"title":2},"66":{"body":81,"breadcrumbs":7,"title":2},"660":{"body":33,"breadcrumbs":7,"title":4},"661":{"body":31,"breadcrumbs":4,"title":1},"662":{"body":106,"breadcrumbs":5,"title":2},"663":{"body":78,"breadcrumbs":6,"title":3},"664":{"body":326,"breadcrumbs":4,"title":1},"665":{"body":26,"breadcrumbs":5,"title":2},"666":{"body":0,"breadcrumbs":5,"title":2},"667":{"body":113,"breadcrumbs":8,"title":5},"668":{"body":38,"breadcrumbs":5,"title":2},"669":{"body":58,"breadcrumbs":7,"title":2},"67":{"body":60,"breadcrumbs":8,"title":3},"670":{"body":1,"breadcrumbs":7,"title":2},"671":{"body":21,"breadcrumbs":6,"title":2},"672":{"body":36,"breadcrumbs":6,"title":2},"673":{"body":1,"breadcrumbs":6,"title":2},"674":{"body":102,"breadcrumbs":6,"title":3},"675":{"body":27,"breadcrumbs":5,"title":2},"676":{"body":36,"breadcrumbs":7,"title":4},"677":{"body":71,"breadcrumbs":6,"title":3},"678":{"body":1,"breadcrumbs":5,"title":2},"679":{"body":21,"breadcrumbs":6,"title":2},"68":{"body":54,"breadcrumbs":8,"title":3},"680":{"body":29,"breadcrumbs":5,"title":1},"681":{"body":0,"breadcrumbs":6,"title":2},"682":{"body":98,"breadcrumbs":5,"title":1},"683":{"body":54,"breadcrumbs":5,"title":1},"684":{"body":54,"breadcrumbs":5,"title":1},"685":{"body":83,"breadcrumbs":5,"title":1},"686":{"body":60,"breadcrumbs":5,"title":1},"687":{"body":0,"breadcrumbs":6,"title":2},"688":{"body":94,"breadcrumbs":7,"title":3},"689":{"body":156,"breadcrumbs":6,"title":2},"69":{"body":97,"breadcrumbs":8,"title":3},"690":{"body":58,"breadcrumbs":5,"title":2},"691":{"body":40,"breadcrumbs":5,"title":2},"692":{"body":53,"breadcrumbs":7,"title":4},"693":{"body":33,"breadcrumbs":6,"title":3},"694":{"body":8,"breadcrumbs":4,"title":1},"695":{"body":0,"breadcrumbs":4,"title":1},"696":{"body":105,"breadcrumbs":4,"title":1},"697":{"body":0,"breadcrumbs":4,"title":1},"698":{"body":136,"breadcrumbs":4,"title":1},"699":{"body":19,"breadcrumbs":4,"title":1},"7":{"body":47,"breadcrumbs":3,"title":2},"70":{"body":0,"breadcrumbs":7,"title":2},"700":{"body":0,"breadcrumbs":4,"title":1},"701":{"body":271,"breadcrumbs":5,"title":2},"702":{"body":0,"breadcrumbs":5,"title":2},"703":{"body":28,"breadcrumbs":5,"title":2},"704":{"body":76,"breadcrumbs":6,"title":2},"705":{"body":105,"breadcrumbs":6,"title":2},"706":{"body":70,"breadcrumbs":8,"title":4},"707":{"body":0,"breadcrumbs":6,"title":2},"708":{"body":43,"breadcrumbs":7,"title":3},"709":{"body":79,"breadcrumbs":7,"title":3},"71":{"body":79,"breadcrumbs":9,"title":4},"710":{"body":10,"breadcrumbs":5,"title":1},"711":{"body":10,"breadcrumbs":5,"title":1},"712":{"body":35,"breadcrumbs":5,"title":1},"713":{"body":106,"breadcrumbs":5,"title":1},"714":{"body":92,"breadcrumbs":6,"title":2},"715":{"body":0,"breadcrumbs":5,"title":1},"716":{"body":22,"breadcrumbs":7,"title":3},"717":{"body":98,"breadcrumbs":6,"title":2},"718":{"body":0,"breadcrumbs":6,"title":2},"719":{"body":92,"breadcrumbs":8,"title":4},"72":{"body":25,"breadcrumbs":11,"title":6},"720":{"body":30,"breadcrumbs":7,"title":3},"721":{"body":50,"breadcrumbs":7,"title":3},"722":{"body":22,"breadcrumbs":7,"title":3},"723":{"body":31,"breadcrumbs":7,"title":3},"724":{"body":15,"breadcrumbs":5,"title":2},"725":{"body":43,"breadcrumbs":4,"title":1},"726":{"body":147,"breadcrumbs":7,"title":4},"727":{"body":58,"breadcrumbs":5,"title":2},"728":{"body":27,"breadcrumbs":5,"title":2},"729":{"body":67,"breadcrumbs":5,"title":2},"73":{"body":63,"breadcrumbs":10,"title":5},"730":{"body":49,"breadcrumbs":4,"title":1},"731":{"body":161,"breadcrumbs":2,"title":1},"732":{"body":0,"breadcrumbs":3,"title":2},"733":{"body":9,"breadcrumbs":4,"title":3},"734":{"body":12,"breadcrumbs":4,"title":3},"735":{"body":62,"breadcrumbs":2,"title":1},"736":{"body":12,"breadcrumbs":2,"title":1},"737":{"body":34,"breadcrumbs":4,"title":3},"738":{"body":38,"breadcrumbs":4,"title":3},"739":{"body":13,"breadcrumbs":4,"title":3},"74":{"body":17,"breadcrumbs":11,"title":4},"740":{"body":27,"breadcrumbs":4,"title":3},"741":{"body":27,"breadcrumbs":4,"title":3},"742":{"body":45,"breadcrumbs":2,"title":1},"743":{"body":19,"breadcrumbs":3,"title":2},"744":{"body":34,"breadcrumbs":4,"title":3},"745":{"body":57,"breadcrumbs":4,"title":3},"746":{"body":33,"breadcrumbs":2,"title":1},"747":{"body":31,"breadcrumbs":2,"title":1},"748":{"body":50,"breadcrumbs":3,"title":2},"749":{"body":36,"breadcrumbs":3,"title":2},"75":{"body":122,"breadcrumbs":8,"title":1},"750":{"body":9,"breadcrumbs":3,"title":2},"751":{"body":80,"breadcrumbs":2,"title":1},"752":{"body":34,"breadcrumbs":3,"title":2},"753":{"body":41,"breadcrumbs":5,"title":4},"754":{"body":21,"breadcrumbs":4,"title":3},"755":{"body":20,"breadcrumbs":3,"title":2},"756":{"body":9,"breadcrumbs":3,"title":2},"757":{"body":15,"breadcrumbs":2,"title":1},"758":{"body":21,"breadcrumbs":4,"title":3},"759":{"body":46,"breadcrumbs":3,"title":2},"76":{"body":41,"breadcrumbs":9,"title":2},"760":{"body":53,"breadcrumbs":2,"title":1},"761":{"body":10,"breadcrumbs":2,"title":1},"762":{"body":30,"breadcrumbs":3,"title":2},"763":{"body":0,"breadcrumbs":3,"title":2},"764":{"body":48,"breadcrumbs":3,"title":2},"765":{"body":36,"breadcrumbs":4,"title":3},"766":{"body":54,"breadcrumbs":3,"title":2},"767":{"body":77,"breadcrumbs":2,"title":1},"768":{"body":22,"breadcrumbs":3,"title":2},"769":{"body":40,"breadcrumbs":2,"title":1},"77":{"body":18,"breadcrumbs":9,"title":2},"770":{"body":50,"breadcrumbs":3,"title":2},"771":{"body":105,"breadcrumbs":4,"title":3},"772":{"body":97,"breadcrumbs":3,"title":2},"773":{"body":0,"breadcrumbs":5,"title":4},"774":{"body":36,"breadcrumbs":2,"title":1},"775":{"body":20,"breadcrumbs":4,"title":3},"776":{"body":38,"breadcrumbs":4,"title":3},"777":{"body":29,"breadcrumbs":3,"title":2},"778":{"body":45,"breadcrumbs":3,"title":2},"779":{"body":121,"breadcrumbs":4,"title":3},"78":{"body":294,"breadcrumbs":10,"title":3},"780":{"body":21,"breadcrumbs":4,"title":3},"781":{"body":18,"breadcrumbs":4,"title":3},"782":{"body":10,"breadcrumbs":4,"title":3},"783":{"body":25,"breadcrumbs":4,"title":3},"784":{"body":10,"breadcrumbs":4,"title":3},"785":{"body":49,"breadcrumbs":4,"title":3},"786":{"body":21,"breadcrumbs":4,"title":3},"787":{"body":0,"breadcrumbs":4,"title":3},"788":{"body":17,"breadcrumbs":3,"title":2},"789":{"body":91,"breadcrumbs":3,"title":2},"79":{"body":79,"breadcrumbs":11,"title":4},"790":{"body":26,"breadcrumbs":3,"title":2},"791":{"body":22,"breadcrumbs":5,"title":4},"792":{"body":14,"breadcrumbs":4,"title":3},"793":{"body":7,"breadcrumbs":5,"title":4},"794":{"body":46,"breadcrumbs":2,"title":1},"795":{"body":14,"breadcrumbs":3,"title":2},"796":{"body":32,"breadcrumbs":3,"title":2},"797":{"body":36,"breadcrumbs":3,"title":2},"798":{"body":21,"breadcrumbs":3,"title":2},"799":{"body":0,"breadcrumbs":4,"title":3},"8":{"body":51,"breadcrumbs":3,"title":2},"80":{"body":79,"breadcrumbs":10,"title":3},"800":{"body":71,"breadcrumbs":3,"title":2},"81":{"body":23,"breadcrumbs":10,"title":5},"82":{"body":74,"breadcrumbs":6,"title":1},"83":{"body":36,"breadcrumbs":9,"title":4},"84":{"body":112,"breadcrumbs":7,"title":2},"85":{"body":128,"breadcrumbs":9,"title":4},"86":{"body":153,"breadcrumbs":10,"title":5},"87":{"body":17,"breadcrumbs":6,"title":1},"88":{"body":0,"breadcrumbs":7,"title":2},"89":{"body":36,"breadcrumbs":7,"title":2},"9":{"body":27,"breadcrumbs":3,"title":2},"90":{"body":81,"breadcrumbs":9,"title":3},"91":{"body":29,"breadcrumbs":8,"title":2},"92":{"body":34,"breadcrumbs":9,"title":3},"93":{"body":54,"breadcrumbs":9,"title":3},"94":{"body":16,"breadcrumbs":7,"title":1},"95":{"body":56,"breadcrumbs":8,"title":2},"96":{"body":22,"breadcrumbs":11,"title":5},"97":{"body":19,"breadcrumbs":11,"title":5},"98":{"body":419,"breadcrumbs":12,"title":6},"99":{"body":0,"breadcrumbs":8,"title":2}},"docs":{"0":{"body":"Table of Contents About Optimism About the OP Stack Site Navigation","breadcrumbs":"Introduction » OP Stack Specification","id":"0","title":"OP Stack Specification"},"1":{"body":"Optimism is a project dedicated to scaling Ethereum's technology and expanding its ability to coordinate people from across the world to build effective decentralized economies and governance systems. The Optimism Collective builds open-source software that powers scalable blockchains and aims to address key governance and economic challenges in the wider Ethereum ecosystem. Optimism operates on the principle of impact=profit , the idea that individuals who positively impact the Collective should be proportionally rewarded with profit. Change the incentives and you change the world.","breadcrumbs":"Introduction » About Optimism","id":"1","title":"About Optimism"},"10":{"body":"We strive to preserve three critical properties: liveness, validity, and availability. A protocol that can maintain these properties can, effectively, scale Ethereum without sacrificing security.","breadcrumbs":"Background » Protocol Guarantees","id":"10","title":"Protocol Guarantees"},"100":{"body":"This updates which L2 blocks the engine considers to be canonical (forkchoiceState argument), and optionally initiates block production (payloadAttributes argument). Within the rollup, the types of forkchoice updates translate as: headBlockHash: block hash of the head of the canonical chain. Labeled \"unsafe\" in user JSON-RPC. Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts. safeBlockHash: block hash of the canonical chain, derived from L1 data, unlikely to reorg. finalizedBlockHash: irreversible block hash, matches lower boundary of the dispute period. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV2 : the extended PayloadAttributesV2 Extended PayloadAttributesV2 PayloadAttributesV2 is extended to: PayloadAttributesV2: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The type notation used here refers to the HEX value encoding used by the Ethereum JSON-RPC API specification , as this structure will need to be sent over JSON-RPC. array refers to a JSON array. Each item of the transactions array is a byte list encoding a transaction: TransactionType || TransactionPayload or LegacyTransaction, as defined in EIP-2718 . This is equivalent to the transactions field in ExecutionPayloadV2 The transactions field is optional: If empty or missing: no changes to engine behavior. The sequencers will (if enabled) build a block by consuming transactions from the transaction pool. If present and non-empty: the payload MUST be produced starting with this exact list of transactions. The rollup driver determines the transaction list based on deterministic L1 inputs. The noTxPool is optional as well, and extends the transactions meaning: If false, the execution engine is free to pack additional transactions from external sources like the tx pool into the payload, after any of the transactions. This is the default behavior a L1 node implements. If true, the execution engine must not change anything about the given list of transactions. If the transactions field is present, the engine must execute the transactions in order and return STATUS_INVALID if there is an error processing the transactions. It must return STATUS_VALID if all of the transactions could be executed without error. Note : The state transition rules have been modified such that deposits will never fail so if engine_forkchoiceUpdatedV2 returns STATUS_INVALID it is because a batched transaction is invalid. The gasLimit is optional w.r.t. compatibility with L1, but required when used as rollup. This field overrides the gas limit used during block-building. If not specified as rollup, a STATUS_INVALID is returned.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV2","id":"100","title":"engine_forkchoiceUpdatedV2"},"101":{"body":"See engine_forkchoiceUpdatedV2 for a description of the forkchoice updated method. engine_forkchoiceUpdatedV3 must only be called with Ecotone payload. To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV3 : the extended PayloadAttributesV3 Extended PayloadAttributesV3 PayloadAttributesV3 is extended to: PayloadAttributesV3: { timestamp: QUANTITY random: DATA (32 bytes) suggestedFeeRecipient: DATA (20 bytes) withdrawals: array of WithdrawalV1 parentBeaconBlockRoot: DATA (32 bytes) transactions: array of DATA noTxPool: bool gasLimit: QUANTITY or null\n} The requirements of this object are the same as extended PayloadAttributesV2 with the addition of parentBeaconBlockRoot which is the parent beacon block root from the L1 origin block of the L2 block. Starting at Ecotone, the parentBeaconBlockRoot must be set to the L1 origin parentBeaconBlockRoot, or a zero bytes32 if the Dencun functionality with parentBeaconBlockRoot is not active on L1.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_forkchoiceUpdatedV3","id":"101","title":"engine_forkchoiceUpdatedV3"},"102":{"body":"No modifications to engine_newPayloadV2 . Applies a L2 block to the engine state.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV2","id":"102","title":"engine_newPayloadV2"},"103":{"body":"engine_newPayloadV3 applies an Ecotone L2 block to the engine state. There are no modifications to this API. engine_newPayloadV3 must only be called with Ecotone payload. The additional parameters should be set as follows: expectedBlobVersionedHashes MUST be an empty array. parentBeaconBlockRoot MUST be the parent beacon block root from the L1 origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_newPayloadV3","id":"103","title":"engine_newPayloadV3"},"104":{"body":"No modifications to engine_getPayloadV2 . Retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV2 when called with payloadAttributes.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV2","id":"104","title":"engine_getPayloadV2"},"105":{"body":"engine_getPayloadV3 retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV3 when called with payloadAttributes. engine_getPayloadV3 must only be called with Ecotone payload. Extended Response The response is extended to: { executionPayload: ExecutionPayload blockValue: QUANTITY blobsBundle: BlobsBundle shouldOverrideBuilder: BOOLEAN parentBeaconBlockRoot: DATA (32 bytes)\n} In Ecotone it MUST be set to the parentBeaconBlockRoot from the L1 Origin block of the L2 block.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_getPayloadV3","id":"105","title":"engine_getPayloadV3"},"106":{"body":"Optional extension to the Engine API. Signals superchain information to the Engine: V1 signals which protocol version is recommended and required. Types: SuperchainSignal: { recommended: ProtocolVersion; required: ProtocolVersion;\n} ProtocolVersion: encoded for RPC as defined in Protocol Version format specification . Parameters: signal: SuperchainSignal, the signaled superchain information. Returns: ProtocolVersion: the latest supported OP-Stack protocol version of the execution engine. The execution engine SHOULD warn the user when the recommended version is newer than the current version supported by the execution engine. The execution engine SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the execution engine operator.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » engine_signalSuperchainV1","id":"106","title":"engine_signalSuperchainV1"},"107":{"body":"The execution engine can acquire all data through the rollup node, as derived from L1: P2P networking is strictly optional. However, to not bottleneck on L1 data retrieval speed, the P2P network functionality SHOULD be enabled, serving: Peer discovery ( Disc v5 ) eth/66 : Transaction pool (consumed by sequencer nodes) State sync (happy-path for fast trustless db replication) Historical block header and body retrieval New blocks are acquired through the consensus layer instead (rollup node) No modifications to L1 network functionality are required, except configuration: networkID : Distinguishes the L2 network from L1 and testnets. Equal to the chainID of the rollup network. Activate Merge fork: Enables Engine API and disables propagation of blocks, as block headers cannot be authenticated without consensus layer. Bootnode list: DiscV5 is a shared network, bootstrap is faster through connecting with L2 nodes first.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Networking","id":"107","title":"Networking"},"108":{"body":"The execution engine can operate sync in different ways: Happy-path: rollup node informs engine of the desired chain head as determined by L1, completes through engine P2P. Worst-case: rollup node detects stalled engine, completes sync purely from L1 data, no peers required. The happy-path is more suitable to bring new nodes online quickly, as the engine implementation can sync state faster through methods like snap-sync .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Sync","id":"108","title":"Sync"},"109":{"body":"The rollup node informs the engine of the L2 chain head, unconditionally (part of regular node operation): Bedrock / Canyon / Delta Payloads engine_newPayloadV2 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV2 is called with the current unsafe/safe/finalized L2 block hashes. Ecotone Payloads engine_newPayloadV3 is called with latest L2 block received from P2P. engine_forkchoiceUpdatedV3 is called with the current unsafe/safe/finalized L2 block hashes. The engine requests headers from peers, in reverse till the parent hash matches the local chain The engine catches up: a) A form of state sync is activated towards the finalized or head block hash b) A form of block sync pulls block bodies and processes towards head block hash The exact P2P based sync is out of scope for the L2 specification: the operation within the engine is the exact same as with L1 (although with an EVM that supports deposits).","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Happy-path sync","id":"109","title":"Happy-path sync"},"11":{"body":"Liveness is defined as the ability for any party to be able to extend the rollup chain by including a transaction within a bounded amount of time. It should not be possible for an actor to block the inclusion of any given transaction for more than this bounded time period. This bounded time period should also be acceptable such that inclusion is not just theoretically possible but practically useful.","breadcrumbs":"Background » Liveness","id":"11","title":"Liveness"},"110":{"body":"Engine is out of sync, not peered and/or stalled due other reasons. The rollup node maintains latest head from engine (poll eth_getBlockByNumber and/or maintain a header subscription) The rollup node activates sync if the engine is out of sync but not syncing through P2P (eth_syncing) The rollup node inserts blocks, derived from L1, one by one, potentially adapting to L1 reorg(s), as outlined in the rollup node spec .","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Worst-case sync","id":"110","title":"Worst-case sync"},"111":{"body":"EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction, plus a list of \"blobs\": \"Binary Large Object\", i.e. a dedicated data type for serving Data-Availability as base-layer. With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception: as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type. EIP-4844 is disabled as following: Transaction network-layer announcements, announcing blob-type transactions, are ignored. Transactions of the blob-type, through the RPC or otherwise, are not allowed into the transaction pool. Block-building code does not select EIP-4844 transactions. An L2 block state-transition with EIP-4844 transactions is invalid. The BLOBBASEFEE opcode is present but its semantics are altered because there are no blobs processed by L2. The opcode will always push a value of 1 onto the stack.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: disable Blob-transactions","id":"111","title":"Ecotone: disable Blob-transactions"},"112":{"body":"EIP-4788 introduces a \"beacon block root\" into the execution-layer block-header and EVM. This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block. With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO of L1. And thus with EIP-4788 the L1 beacon block root is made available. For the Ecotone upgrade, this entails that: The parent_beacon_block_root of the L1 origin is now embedded in the L2 block header. The \"Beacon roots contract\" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis. The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » Ecotone: Beacon Block Root","id":"112","title":"Ecotone: Beacon Block Root"},"113":{"body":"The Ethereum Node Record (ENR) for an Optimism execution node must contain an opel key-value pair where the key is opel and the value is a EIP-2124 fork id. The EL uses a different key from the CL in order to stop EL and CL nodes from connecting to each other.","breadcrumbs":"OP Stack Protocol » Clients » Execution Engine » P2P Modifications","id":"113","title":"P2P Modifications"},"114":{"body":"Table of Contents Overview Driver Derivation L2 Output RPC method Structures BlockID L1BlockRef L2BlockRef SyncStatus Output Method API Protocol Version tracking","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node Specification","id":"114","title":"Rollup Node Specification"},"115":{"body":"The rollup node is the component responsible for deriving the L2 chain from L1 blocks (and their associated receipts ). The part of the rollup node that derives the L2 chain is called the rollup driver . This document is currently only concerned with the specification of the rollup driver.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Overview","id":"115","title":"Overview"},"116":{"body":"The task of the driver in the rollup node is to manage the derivation process: Keep track of L1 head block Keep track of the L2 chain sync progress Iterate over the derivation steps as new inputs become available","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Driver","id":"116","title":"Driver"},"117":{"body":"This process happens in three steps: Select inputs from the L1 chain, on top of the last L2 block: a list of blocks, with transactions and associated data and receipts. Read L1 information, deposits, and sequencing batches in order to generate payload attributes (essentially a block without output properties ). Pass the payload attributes to the execution engine , so that the L2 block (including output block properties ) may be computed. While this process is conceptually a pure function from the L1 chain to the L2 chain, it is in practice incremental. The L2 chain is extended whenever new L1 blocks are added to the L1 chain. Similarly, the L2 chain re-organizes whenever the L1 chain re-organizes . For a complete specification of the L2 block derivation, refer to the L2 block derivation document .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation","id":"117","title":"Derivation"},"118":{"body":"The Rollup node has its own RPC method, optimism_outputAtBlock which returns a 32 byte hash corresponding to the L2 output root .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » L2 Output RPC method","id":"118","title":"L2 Output RPC method"},"119":{"body":"These define the types used by rollup node API methods. The types defined here are extended from the engine API specs . BlockID hash: DATA, 32 Bytes number: QUANTITY, 64 Bits L1BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits L2BlockRef hash: DATA, 32 Bytes number: QUANTITY, 64 Bits parentHash: DATA, 32 Bytes timestamp: QUANTITY, 64 Bits l1origin: BlockID sequenceNumber: QUANTITY, 64 Bits - distance to first block of epoch SyncStatus Represents a snapshot of the rollup driver. current_l1: Object - instance of L1BlockRef . current_l1_finalized: Object - instance of L1BlockRef . head_l1: Object - instance of L1BlockRef . safe_l1: Object - instance of L1BlockRef . finalized_l1: Object - instance of L1BlockRef . unsafe_l2: Object - instance of L2BlockRef . safe_l2: Object - instance of L2BlockRef . finalized_l2: Object - instance of L2BlockRef . pending_safe_l2: Object - instance of L2BlockRef . queued_unsafe_l2: Object - instance of L2BlockRef .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Structures","id":"119","title":"Structures"},"12":{"body":"Validity is defined as the ability for any party to execute the rollup state transition function, subject to certain lower bound expectations for available computing and bandwidth resources. Validity is also extended to refer to the ability for a smart contract on Ethereum to be able to validate this state transition function economically.","breadcrumbs":"Background » Validity","id":"12","title":"Validity"},"120":{"body":"The input and return types here are as defined by the engine API specs . method: optimism_outputAtBlock params: blockNumber: QUANTITY, 64 bits - L2 integer block number. returns: version: DATA, 32 Bytes - the output root version number, beginning with 0. outputRoot: DATA, 32 Bytes - the output root. blockRef: Object - instance of L2BlockRef . withdrawalStorageRoot: 32 bytes - storage root of the L2toL1MessagePasser contract. stateRoot: DATA: 32 bytes - the state root. syncStatus: Object - instance of SyncStatus .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Output Method API","id":"120","title":"Output Method API"},"121":{"body":"The rollup-node should monitor the recommended and required protocol version by monitoring the Protocol Version contract on L1, as specified in the Superchain Version Signaling specifications . This can be implemented through polling in the Driver loop. After polling the Protocol Version, the rollup node SHOULD communicate it with the execution-engine through an engine_signalSuperchainV1 call. The rollup node SHOULD warn the user when the recommended version is newer than the current version supported by the rollup node. The rollup node SHOULD take safety precautions if it does not meet the required protocol version. This may include halting the engine, with consent of the rollup node operator.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Protocol Version tracking","id":"121","title":"Protocol Version tracking"},"122":{"body":"Table of Contents Overview P2P configuration Identification Discv5 Consensus Layer Structure LibP2P Transport Dialing NAT Peer management Transport security Protocol negotiation Identify Ping Multiplexing GossipSub Content-based message identification Message compression and limits Message ID computation Heartbeat and parameters Topic configuration Topic validation Gossip Topics blocksv1 blocksv2 blocksv3 Block encoding Block signatures Block validation Block processing Block topic scoring parameters Req-Resp payload_by_number","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Rollup-node P2P interface","id":"122","title":"Rollup-node P2P interface"},"123":{"body":"The rollup node has an optional peer-to-peer (P2P) network service to improve the latency between the view of sequencers and the rest of the network by bypassing the L1 in the happy case, without relying on a single centralized endpoint. This also enables faster historical sync to be bootstrapped by providing block headers to sync towards, and only having to compare the L2 chain inputs to the L1 data as compared to processing everything one block at a time. The rollup node will always prioritize L1 and reorganize to match the canonical chain. The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the \"unsafe\" chain, to improve the happy case performance. This also means that P2P behavior is a soft-rule: nodes keep each other in check with scoring and eventual banning of malicious peers by identity or IP. Any behavior on the P2P layer does not affect the rollup security, at worst nodes rely on higher-latency data from L1 to serve. In summary, the P2P stack looks like: Discovery to find peers: Discv5 Connections, peering, transport security, multiplexing, gossip: LibP2P Application-layer publishing and validation of gossiped messages like L2 blocks. This document only specifies the composition and configuration of these network libraries. These components have their own standards, implementations in Go/Rust/Java/Nim/JS/more, and are adopted by several other blockchains, most notably the L1 consensus layer (Eth2) .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Overview","id":"123","title":"Overview"},"124":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » P2P configuration","id":"124","title":"P2P configuration"},"125":{"body":"Nodes have a separate network- and consensus-identity. The network identity is a secp256k1 key, used for both discovery and active LibP2P connections. Common representations of network identity: PeerID: a LibP2P specific ID derived from the pubkey (through protobuf encoding, typing and hashing) NodeID: a Discv5 specific ID derived from the pubkey (through hashing, used in the DHT) Multi-address: an unsigned address, containing: IP, TCP port, PeerID ENR: a signed record used for discovery, containing: IP, TCP port, UDP port, signature (pubkey can be derived) and L2 network identification. Generally encoded in base64.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Identification","id":"125","title":"Identification"},"126":{"body":"Consensus Layer Structure The Ethereum Node Record (ENR) for an Optimism rollup node must contain the following values, identified by unique keys: An IPv4 address (ip field) and/or IPv6 address (ip6 field). A TCP port (tcp field) representing the local libp2p listening port. A UDP port (udp field) representing the local discv5 listening port. An OpStack (opstack field) L2 network identifier The opstack value is encoded as a single RLP bytes value, the concatenation of: chain ID (unsigned varint) fork ID (unsigned varint) Note that DiscV5 is a shared DHT (Distributed Hash Table): the L1 consensus and execution nodes, as well as testnet nodes, and even external IOT nodes, all communicate records in this large common DHT. This makes it more difficult to censor the discovery of node records. The discovery process in Optimism is a pipeline of node records: Fill the table with FINDNODES if necessary (Performed by Discv5 library) Pull additional records with searches to random Node IDs if necessary (e.g. iterate RandomNodes() in Go implementation) Pull records from the DiscV5 module when looking for peers Check if the record contains the opstack entry, verify it matches the chain ID and current or future fork number If not already connected, and not recently disconnected or put on deny-list, attempt to dial.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Discv5","id":"126","title":"Discv5"},"127":{"body":"Transport TCP transport. Additional transports are supported by LibP2P, but not required. Dialing Nodes should be publicly dialable, not rely on relay extensions, and able to dial both IPv4 and IPv6. NAT The listening endpoint must be publicly facing, but may be configured behind a NAT. LibP2P will use PMP / UPNP based techniques to track the external IP of the node. It is recommended to disable the above if the external IP is static and configured manually. Peer management The default is to maintain a peer count with a tide-system based on active peer count: At \"low tide\" the node starts to actively search for additional peer connections. At \"high tide\" the node starts to prune active connections, except those that are marked as trusted or have a grace period. Peers will have a grace period for a configurable amount of time after joining. In an emergency, when memory runs low, the node should start pruning more aggressively. Peer records can be persisted to disk to quickly reconnect with known peers after restarting the rollup node. The discovery process feeds the peerstore with peer records to connect to, tagged with a time-to-live (TTL). The current P2P processes do not require selective topic-specific peer connections, other than filtering for the basic network participation requirement. Peers may be banned if their performance score is too low, or if an objectively malicious action was detected. Banned peers will be persisted to the same data-store as the peerstore records. TODO: the connection gater does currently not gate by IP address on the dial Accept-callback. Transport security Libp2p-noise , XX handshake, with the secp256k1 P2P identity, as popularized in Eth2. The TLS option is available as well, but noise should be prioritized in negotiation. Protocol negotiation Multistream-select 1.0 (/multistream/1.0.0) is an interactive protocol used to negotiate sub-protocols supported in LibP2P peers. Multistream-select 2.0 may be used in the future. Identify LibP2P offers a minimal identification module to share client version and programming language. This is optional and can be disabled for enhanced privacy. It also includes the same protocol negotiation information, which can speed up initial connections. Ping LibP2P includes a simple ping protocol to track latency between connections. This should be enabled to help provide insight into the network health. Multiplexing For async communication over different channels over the same connection, multiplexing is used. mplex (/mplex/6.7.0) is required, and yamux (/yamux/1.0.0) is recommended but optional GossipSub GossipSub 1.1 (/meshsub/1.1.0, i.e. with peer-scoring extension) is a pubsub protocol for mesh-networks, deployed on L1 consensus (Eth2) and other protocols such as Filecoin, offering lots of customization options. Content-based message identification Messages are deduplicated, and filtered through application-layer signature verification. Thus origin-stamping is disabled and published messages must only contain application data, enforced through a StrictNoSign Signature Policy This provides greater privacy, and allows sequencers (consensus identity) to maintain multiple network identities for redundancy. Message compression and limits The application contents are compressed with snappy single-block-compression (as opposed to frame-compression), and constrained to 10 MiB. Message ID computation Same as L1 , with recognition of compression: If message.data has a valid snappy decompression, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_VALID_SNAPPY with the snappy decompressed message data, i.e. SHA256(MESSAGE_DOMAIN_VALID_SNAPPY + snappy_decompress(message.data))[:20]. Otherwise, set message-id to the first 20 bytes of the SHA256 hash of the concatenation of MESSAGE_DOMAIN_INVALID_SNAPPY with the raw message data, i.e. SHA256(MESSAGE_DOMAIN_INVALID_SNAPPY + message.data)[:20]. Heartbeat and parameters GossipSub parameters : D (topic stable mesh target count): 8 D_low (topic stable mesh low watermark): 6 D_high (topic stable mesh high watermark): 12 D_lazy (gossip target): 6 heartbeat_interval (interval of heartbeat, in seconds): 0.5 fanout_ttl (ttl for fanout maps for topics we are not subscribed to but have published to, in seconds): 24 mcache_len (number of windows to retain full messages in cache for IWANT responses): 12 mcache_gossip (number of windows to gossip about): 3 seen_ttl (number of heartbeat intervals to retain message IDs): 130 (= 65 seconds) Notable differences from L1 consensus (Eth2): seen_ttl does not need to cover a full L1 epoch (6.4 minutes), but rather just a small window covering latest blocks fanout_ttl: adjusted to lower than seen_ttl mcache_len: a larger number of heartbeats can be retained since the gossip is much less noisy. heartbeat_interval: faster interval to reduce latency, bandwidth should still be reasonable since there are far fewer messages to gossip about each interval than on L1 which uses an interval of 0.7 seconds. Topic configuration Topics have string identifiers and are communicated with messages and subscriptions. /optimism/chain_id/hardfork_version/Name chain_id: replace with decimal representation of chain ID hardfork_version: replace with decimal representation of hardfork, starting at 0 Name: topic application-name Note that the topic encoding depends on the topic, unlike L1, since there are less topics, and all are snappy-compressed. Topic validation To ensure only valid messages are relayed, and malicious peers get scored based on application behavior, an extended validator checks the message before it is relayed or processed. The extended validator emits one of the following validation signals: ACCEPT valid, relayed to other peers and passed to local topic subscriber IGNORE scored like inactivity, message is dropped and not processed REJECT score penalties, message is dropped","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » LibP2P","id":"127","title":"LibP2P"},"128":{"body":"There are three topics for distributing blocks to other nodes faster than proxying through L1 would. These are:","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Gossip Topics","id":"128","title":"Gossip Topics"},"129":{"body":"Pre-Canyon/Shanghai blocks are broadcast on /optimism//0/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv1","id":"129","title":"blocksv1"},"13":{"body":"Availability is defined as the ability for any party to retrieve the inputs that are necessary to execute the rollup state transition function correctly. Availability is essentially an element of validity and is required to be able to guarantee validity in general. Similar to validity, availability is subject to lower bound resource requirements.","breadcrumbs":"Background » Availability","id":"13","title":"Availability"},"130":{"body":"Canyon/Delta blocks are broadcast on /optimism//1/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv2","id":"130","title":"blocksv2"},"131":{"body":"Ecotone blocks are broadcast on /optimism//2/blocks.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » blocksv3","id":"131","title":"blocksv3"},"132":{"body":"A block is structured as the concatenation of: V1 and V2 topics signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. V3 topic signature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8) parentBeaconBlockRoot: L1 origin parent beacon block root, always 32 bytes payload: A SSZ-encoded ExecutionPayload, always the remaining bytes. All topics use Snappy block-compression (i.e. no snappy frames): the above needs to be compressed after encoding, and decompressed before decoding.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block encoding","id":"132","title":"Block encoding"},"133":{"body":"The signature is a secp256k1 signature, and signs over a message: keccak256(domain ++ chain_id ++ payload_hash), where: domain is 32 bytes, reserved for message types and versioning info. All zero for this signature. chain_id is a big-endian encoded uint256. payload_hash is keccak256(payload), where payload is the payload in V1 and V2, and parentBeaconBlockRoot ++ payload in V3. The secp256k1 signature must have y_parity = 1 or 0, the chain_id is already signed over.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block signatures","id":"133","title":"Block signatures"},"134":{"body":"An extended-validator checks the incoming messages as follows, in order of operation: [REJECT] if the compression is not valid [REJECT] if the block encoding is not valid [REJECT] if the payload.timestamp is older than 60 seconds in the past (graceful boundary for worst-case propagation and clock skew) [REJECT] if the payload.timestamp is more than 5 seconds into the future [REJECT] if the block_hash in the payload is not valid [REJECT] if the block is on the V1 topic and has withdrawals [REJECT] if the block is on the V1 topic and has a withdrawals list [REJECT] if the block is on a topic >= V2 and does not have an empty withdrawals list [REJECT] if the block is on a topic <= V2 and has a blob gas-used value set [REJECT] if the block is on a topic <= V2 and has an excess blob gas value set [REJECT] if the block is on a topic >= V3 and has a blob gas-used value that is not zero [REJECT] if the block is on a topic >= V3 and has an excess blob gas value that is not zero [REJECT] if the block is on a topic <= V2 and the parent beacon block root is not nil [REJECT] if the block is on a topic >= V3 and the parent beacon block root is nil [REJECT] if more than 5 different blocks have been seen with the same block height [IGNORE] if the block has already been seen [REJECT] if the signature by the sequencer is not valid Mark the block as seen for the given block height The block is signed by the corresponding sequencer, to filter malicious messages. The sequencer model is singular but may change to multiple sequencers in the future. A default sequencer pubkey is distributed with rollup nodes and should be configurable. Note that blocks that a block may still be propagated even if the L1 already confirmed a different block. The local L1 view of the node may be wrong, and the time and signature validation will prevent spam. Hence, calling into the execution engine with a block lookup every propagation step is not worth the added delay. Block processing A node may apply the block to their local engine ahead of L1 availability, if it ensures that: The application of the block is reversible, in case of a conflict with delayed L1 information The subsequent forkchoice-update ensures this block is recognized as \"unsafe\" (see fork choice updated ) Block topic scoring parameters TODO: GossipSub per-topic scoring to fine-tune incentives for ideal propagation delay and bandwidth usage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Block validation","id":"134","title":"Block validation"},"135":{"body":"The op-node implements a similar request-response encoding for its sync protocols as the L1 ethereum Beacon-Chain. See L1 P2P-interface req-resp specification and Altair P2P update . However, the protocol is simplified, to avoid several issues seen in L1: Error strings in responses, if there is any alternative response, should not need to be compressed or have an artificial global length limit. Payload lengths should be fixed-length: byte-by-byte uvarint reading from the underlying stream is undesired. are relaxed to encode a uint32, rather than a beacon-chain ForkDigest. Payload-encoding may change per hardfork, so is not part of the protocol-ID. Usage of response-chunks is specific to the req-resp method: most basic req-resp does not need chunked responses. Compression is encouraged to be part of the payload-encoding, specific to the req-resp method, where necessary: pings and such do not need streaming frame compression etc. And the protocol ID format follows the same scheme as L1, except the trailing encoding schema part, which is now message-specific: /ProtocolPrefix/MessageName/SchemaVersion/ The req-resp protocols served by the op-node all have /ProtocolPrefix set to /opstack/req. Individual methods may include the chain ID as part of the /MessageName segment, so it's immediately clear which chain the method applies to, if the communication is chain-specific. Other methods may include chain-information in the request and/or response data, such as the ForkDigest in L1 beacon chain req-resp protocols. Each segment starts with a /, and may contain multiple /, and the final protocol ID is suffixed with a /.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » Req-Resp","id":"135","title":"Req-Resp"},"136":{"body":"This is an optional chain syncing method, to request/serve execution payloads by number. This serves as a method to fill gaps upon missed gossip, and sync short to medium ranges of unsafe L2 blocks. Protocol ID: /opstack/req/payload_by_number//0/ /MessageName is /block_by_number/ where is set to the op-node L2 chain ID. /SchemaVersion is /0 Request format: : a little-endian uint64 - the block number to request. Response format: = is a byte code describing the result. 0 on success, should follow. 1 if valid request, but unavailable payload. 2 if invalid request 3+ if other error The >= 128 range is reserved for future use. is a little-endian uint32, identifying the response type (fork-specific) is an encoded block, read till stream EOF. The input of should be limited, as well as any generated decompressed output, to avoid unexpected resource usage or zip-bomb type attacks. A 10 MB limit is recommended, to ensure all blocks may be synced. Implementations may opt for a different limit, since this sync method is optional. list: 0: SSZ-encoded ExecutionPayload, with Snappy framing compression, matching the ExecutionPayload SSZ definition of the L1 Merge, L2 Bedrock and L2 Regolith, L2 Canyon versions. 1: SSZ-encoded ExecutionPayloadEnvelope with Snappy framing compression, matching the ExecutionPayloadEnvelope SSZ definition of the L2 Ecotone version. The request is by block-number, enabling parallel fetching of a chain across many peers. A res = 0 response should be verified to: Have a block-number matching the requested block number. Have a consistent blockhash w.r.t. the other block contents. Build towards a known canonical block. This can be verified by checking if the parent-hash of a previous trusted canonical block matches that of the verified hash of the retrieved block. For unsafe blocks this may be relaxed to verification against the parent-hash of any previously trusted block: The gossip validation process limits the amount of blocks that may be trusted to sync towards. The unsafe blocks should be queued for processing, the latest received L2 unsafe blocks should always override any previous chain, until the final L2 chain can be reproduced from L1 data. A res > 0 response code should not be accepted. The result code is helpful for debugging, but the client should regard any error like any other unanswered request, as the responding peer cannot be trusted.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Rollup Node P2P » payload_by_number","id":"136","title":"payload_by_number"},"137":{"body":"Table of Contents Overview Eager Block Derivation Protocol Parameters Batch Submission Sequencing & Batch Submission Overview Batch Submission Wire Format Batcher Transaction Format Frame Format Channel Format Batch Format Architecture L2 Chain Derivation Pipeline L1 Traversal L1 Retrieval Frame Queue Channel Bank Pruning Timeouts Reading Loading frames Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue Engine API usage Bedrock, Canyon, Delta: API Usage Ecotone: API Usage Forkchoice synchronization L1-consolidation: payload attributes matching L1-sync: payload attributes processing Processing unsafe payload attributes Resetting the Pipeline Finding the sync starting point Resetting derivation stages About reorgs Post-Merge Deriving Payload Attributes Deriving the Transaction List Network upgrade automation transactions Ecotone L1Block Deployment GasPriceOracle Deployment L1Block Proxy Update GasPriceOracle Proxy Update GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) Building Individual Payload Attributes","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Specification","id":"137","title":"L2 Chain Derivation Specification"},"138":{"body":"Note the following assumes a single sequencer and batcher. In the future, the design will be adapted to accommodate multiple such entities. L2 chain derivation — deriving L2 blocks from L1 data — is one of the main responsibilities of the rollup node , both in validator mode, and in sequencer mode (where derivation acts as a sanity check on sequencing, and enables detecting L1 chain re-organizations ). The L2 chain is derived from the L1 chain. In particular, each L1 block following L2 chain inception is mapped to a sequencing epoch comprising at least one L2 block. Each L2 block belongs to exactly one epoch, and we call the corresponding L1 block its L1 origin . The epoch's number equals that of its L1 origin block. To derive the L2 blocks of epoch number E, we need the following inputs: L1 blocks in the range [E, E + SWS), called the sequencing window of the epoch, and SWS the sequencing window size. (Note that sequencing windows overlap.) Batcher transactions from blocks in the sequencing window. These transactions allow us to reconstruct the epoch's sequencer batches , each of which will produce one L2 block. Note that: The L1 origin will never contain any data needed to construct sequencer batches since each batch must contain the L1 origin hash. An epoch may have no sequencer batches. Deposits made in the L1 origin (in the form of events emitted by the deposit contract ). L1 block attributes from the L1 origin (to derive the L1 attributes deposited transaction ). The state of the L2 chain after the last L2 block of the previous epoch, or the L2 genesis state if E is the first epoch. To derive the whole L2 chain from scratch, we start with the L2 genesis state and the L2 genesis block as the first L2 block. We then derive L2 blocks from each epoch in order, starting at the first L1 block following L2 chain inception . Refer to the Architecture section for more information on how we implement this in practice. The L2 chain may contain pre-Bedrock history, but the L2 genesis here refers to the Bedrock L2 genesis block. Each L2 block with origin l1_origin is subject to the following constraints (whose values are denominated in seconds): block.timestamp = prev_l2_timestamp + l2_block_time prev_l2_timestamp is the timestamp of the L2 block immediately preceding this one. If there is no preceding block, then this is the genesis block, and its timestamp is explicitly specified. l2_block_time is a configurable parameter of the time between L2 blocks (2s on Optimism). l1_origin.timestamp <= block.timestamp <= max_l2_timestamp, where max_l2_timestamp = max(l1_origin.timestamp + max_sequencer_drift, prev_l2_timestamp + l2_block_time) max_sequencer_drift is a configurable parameter that bounds how far the sequencer can get ahead of the L1. Finally, each epoch must have at least one L2 block. The first constraint means there must be an L2 block every l2_block_time seconds following L2 chain inception. The second constraint ensures that an L2 block timestamp never precedes its L1 origin timestamp, and is never more than max_sequencer_drift ahead of it, except only in the unusual case where it might prohibit an L2 block from being produced every l2_block_time seconds. (Such cases might arise for example under a proof-of-work L1 that sees a period of rapid L1 block production.) In either case, the sequencer enforces len(batch.transactions) == 0 while max_sequencer_drift is exceeded. See Batch Queue for more details. The final requirement that each epoch must have at least one L2 block ensures that all relevant information from the L1 (e.g. deposits) is represented in the L2, even if it has no sequencer batches. Post-merge, Ethereum has a fixed 12s block time , though some slots can be skipped. Under a 2s L2 block time, we thus expect each epoch to typically contain 12/2 = 6 L2 blocks. The sequencer will however produce bigger epochs in order to maintain liveness in case of either a skipped slot on the L1 or a temporary loss of connection to it. For the lost connection case, smaller epochs might be produced after the connection was restored to keep L2 timestamps from drifting further and further ahead.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Overview","id":"138","title":"Overview"},"139":{"body":"Deriving an L2 block requires that we have constructed its sequencer batch and derived all L2 blocks and state updates prior to it. This means we can typically derive the L2 blocks of an epoch eagerly without waiting on the full sequencing window. The full sequencing window is required before derivation only in the very worst case where some portion of the sequencer batch for the first block of the epoch appears in the very last L1 block of the window. Note that this only applies to block derivation. Sequencer batches can still be derived and tentatively queued without deriving blocks from them.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Eager Block Derivation","id":"139","title":"Eager Block Derivation"},"14":{"body":"Generally speaking, there are three primary actors that interact with an OP Stack chain: users, sequencers, and verifiers. graph TD EthereumL1(Ethereum L1) subgraph \"L2 Participants\" Users(Users) Sequencers(Sequencers) Verifiers(Verifiers) end Verifiers -.->|fetch transaction batches| EthereumL1 Verifiers -.->|fetch deposit data| EthereumL1 Verifiers -->|submit/validate/challenge output proposals| EthereumL1 Verifiers -.->|fetch realtime P2P updates| Sequencers Users -->|submit deposits/withdrawals| EthereumL1 Users -->|submit transactions| Sequencers Users -->|query data| Verifiers Sequencers -->|submit transaction batches| EthereumL1 Sequencers -.->|fetch deposit data| EthereumL1 classDef l1Contracts stroke:#bbf,stroke-width:2px; classDef l2Components stroke:#333,stroke-width:2px; classDef systemUser stroke:#f9a,stroke-width:2px; class EthereumL1 l1Contracts; class Users,Sequencers,Verifiers l2Components;","breadcrumbs":"Background » Network Participants","id":"14","title":"Network Participants"},"140":{"body":"The following table gives an overview of some protocol parameters, and how they are affected by protocol upgrades. Parameter Bedrock (default) value Latest (default) value Changes Notes max_sequencer_drift 600 1800 Fjord Changed from a chain parameter to a constant with Fjord. MAX_RLP_BYTES_PER_CHANNEL 10,000,000 100,000,000 Fjord Constant increased with Fjord. MAX_CHANNEL_BANK_SIZE 100,000,000 1,000,000,000 Fjord Constant increased with Fjord. MAX_SPAN_BATCH_ELEMENT_COUNT 10,000,000 10,000,000 Effectively introduced in Fjord Number of elements","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Protocol Parameters","id":"140","title":"Protocol Parameters"},"141":{"body":"","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission","id":"141","title":"Batch Submission"},"142":{"body":"The sequencer accepts L2 transactions from users. It is responsible for building blocks out of these. For each such block, it also creates a corresponding sequencer batch . It is also responsible for submitting each batch to a data availability provider (e.g. Ethereum calldata), which it does via its batcher component. The difference between an L2 block and a batch is subtle but important: the block includes an L2 state root, whereas the batch only commits to transactions at a given L2 timestamp (equivalently: L2 block number). A block also includes a reference to the previous block (*). (*) This matters in some edge case where a L1 reorg would occur and a batch would be reposted to the L1 chain but not the preceding batch, whereas the predecessor of an L2 block cannot possibly change. This means that even if the sequencer applies a state transition incorrectly, the transactions in the batch will still be considered part of the canonical L2 chain. Batches are still subject to validity checks (i.e. they have to be encoded correctly), and so are individual transactions within the batch (e.g. signatures have to be valid). Invalid batches and invalid individual transactions within an otherwise valid batch are discarded by correct nodes. If the sequencer applies a state transition incorrectly and posts an output root , then this output root will be incorrect. The incorrect output root will be challenged by a fault proof , then replaced by a correct output root for the existing sequencer batches. Refer to the Batch Submission specification for more information.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Sequencing & Batch Submission Overview","id":"142","title":"Sequencing & Batch Submission Overview"},"143":{"body":"Batch submission is closely tied to L2 chain derivation because the derivation process must decode the batches that have been encoded for the purpose of batch submission. The batcher submits batcher transactions to a data availability provider . These transactions contain one or multiple channel frames , which are chunks of data belonging to a channel . A channel is a sequence of sequencer batches (for any L2 blocks) compressed together. The reason to group multiple batches together is simply to obtain a better compression rate, hence reducing data availability costs. Channels might be too large to fit in a single batcher transaction , hence we need to split it into chunks known as channel frames . A single batcher transaction can also carry multiple frames (belonging to the same or to different channels). This design gives use the maximum flexibility in how we aggregate batches into channels, and split channels over batcher transactions. It notably allows us to maximize data utilization in a batcher transaction: for instance it allows us to pack the final (small) frame of one channel with one or more frames from the next channel. Also note that we use a streaming compression scheme, and we do not need to know how many batches a channel will end up containing when we start a channel, or even as we send the first frames in the channel. And by splitting channels across multiple data transactions, the L2 can have larger block data than the data-availability layer may support. All of this is illustrated in the following diagram. Explanations below. batch derivation chain diagram The first line represents L1 blocks with their numbers. The boxes under the L1 blocks represent batcher transactions included within the block. The squiggles under the L1 blocks represent deposits (more specifically, events emitted by the deposit contract ). Each colored chunk within the boxes represents a channel frame . So A and B are channels whereas A0, A1, B0, B1, B2 are frames. Notice that: multiple channels are interleaved frames do not need to be transmitted in order a single batcher transaction can carry frames from multiple channels In the next line, the rounded boxes represent individual sequencer batches that were extracted from the channels. The four blue/purple/pink were derived from channel A while the other were derived from channel B. These batches are here represented in the order they were decoded from batches (in this case B is decoded first). Note The caption here says \"Channel B was seen first and will be decoded into batches first\", but this is not a requirement. For instance, it would be equally acceptable for an implementation to peek into the channels and decode the one that contains the oldest batches first. The rest of the diagram is conceptually distinct from the first part and illustrates L2 chain derivation after the channels have been reordered. The first line shows batcher transactions. Note that in this case, there exists an ordering of the batches that makes all frames within the channels appear contiguously. This is not true in general. For instance, in the second transaction, the position of A1 and B0 could have been inverted for exactly the same result — no changes needed in the rest of the diagram. The second line shows the reconstructed channels in proper order. The third line shows the batches extracted from the channel. Because the channels are ordered and the batches within a channel are sequential, this means the batches are ordered too. The fourth line shows the L2 block derived from each batch. Note that we have a 1-1 batch to block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there are \"gaps\" in the batches posted on L1. The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while the second number (the \"sequence number\") denotes the position within the epoch. Finally, the sixth line shows user-deposited transactions derived from the deposit contract event mentioned earlier. Note the 101-0 L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if frame B2 indicates that it is the last frame within the channel and (2) no empty blocks must be inserted. The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4 blocks, because the last frame of channel A appears in block 102, but belong to epoch 99. As for the comment on \"security types\", it explains the classification of blocks as used on L1 and L2. Unsafe L2 blocks : Safe L2 blocks : Finalized L2 blocks: refer to block that have been derived from finalized L1 data. These security levels map to the headBlockHash, safeBlockHash and finalizedBlockHash values transmitted when interacting with the execution-engine API .","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Submission Wire Format","id":"143","title":"Batch Submission Wire Format"},"144":{"body":"Batcher transactions are encoded as version_byte ++ rollup_payload (where ++ denotes concatenation). version_byte rollup_payload 0 frame ... (one or more frames, concatenated) 1 da_commitment (experimental, see alt-da ) Unknown versions make the batcher transaction invalid (it must be ignored by the rollup node). All frames in a batcher transaction must be parseable. If any one frame fails to parse, the all frames in the transaction are rejected. Batch transactions are authenticated by verifying that the to address of the transaction matches the batch inbox address, and the from address matches the batch-sender address in the system configuration at the time of the L1 block that the transaction data is read from.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batcher Transaction Format","id":"144","title":"Batcher Transaction Format"},"145":{"body":"A channel frame is encoded as: frame = channel_id ++ frame_number ++ frame_data_length ++ frame_data ++ is_last channel_id = bytes16\nframe_number = uint16\nframe_data_length = uint32\nframe_data = bytes\nis_last = bool Where uint32 and uint16 are all big-endian unsigned integers. Type names should be interpreted to and encoded according to the Solidity ABI . All data in a frame is fixed-size, except the frame_data. The fixed overhead is 16 + 2 + 4 + 1 = 23 bytes. Fixed-size frame metadata avoids a circular dependency with the target total data length, to simplify packing of frames with varying content length. where: channel_id is an opaque identifier for the channel. It should not be reused and is suggested to be random; however, outside of timeout rules, it is not checked for validity frame_number identifies the index of the frame within the channel frame_data_length is the length of frame_data in bytes. It is capped to 1,000,000 bytes. frame_data is a sequence of bytes belonging to the channel, logically after the bytes from the previous frames is_last is a single byte with a value of 1 if the frame is the last in the channel, 0 if there are frames in the channel. Any other value makes the frame invalid (it must be ignored by the rollup node).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Format","id":"145","title":"Frame Format"},"146":{"body":"A channel is encoded by applying a streaming compression algorithm to a list of batches: rlp_batches = []\nfor batch in batches: rlp_batches.append(batch) where: batches is the input, a sequence of batches byte-encoded as per the next section (\"Batch Encoding\") rlp_batches is the concatenation of the RLP-encoded batches channel_encoding = zlib_compress(rlp_batches) where zlib_compress is the ZLIB algorithm (as specified in RFC-1950 ) with no dictionary. The Fjord upgrade introduces an additional versioned channel encoding format to support alternate compression algorithms. When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL (defined in the Protocol Parameters table ), in order to avoid \"zip-bomb\" types of attack (where a small compressed input decompresses to a humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained only the first MAX_RLP_BYTES_PER_CHANNEL decompressed bytes. The limit is set on RLP decoding, so all batches that can be decoded in MAX_RLP_BYTES_PER_CHANNEL will be accepted even if the size of the channel is greater than MAX_RLP_BYTES_PER_CHANNEL. The exact requirement is that length(input) <= MAX_RLP_BYTES_PER_CHANNEL. While the above pseudocode implies that all batches are known in advance, it is possible to perform streaming compression and decompression of RLP-encoded batches. This means it is possible to start including channel frames in a batcher transaction before we know how many batches (and how many frames) the channel will contain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Format","id":"146","title":"Channel Format"},"147":{"body":"Recall that a batch contains a list of transactions to be included in a specific L2 block. A batch is encoded as batch_version ++ content, where content depends on the batch_version. Prior to the Delta upgrade, batches all have batch_version 0 and are encoded as described below. batch_version content 0 rlp_encode([parent_hash, epoch_number, epoch_hash, timestamp, transaction_list]) where: batch_version is a single byte, prefixed before the RLP contents, alike to transaction typing. rlp_encode is a function that encodes a batch according to the RLP format , and [x, y, z] denotes a list containing items x, y and z parent_hash is the block hash of the previous L2 block epoch_number and epoch_hash are the number and hash of the L1 block corresponding to the sequencing epoch of the L2 block timestamp is the timestamp of the L2 block transaction_list is an RLP-encoded list of EIP-2718 encoded transactions. The Delta upgrade introduced an additional batch type, span batches . Unknown versions make the batch invalid (it must be ignored by the rollup node), as do malformed contents. The epoch_number and the timestamp must also respect the constraints listed in the Batch Queue section, otherwise the batch is considered invalid and will be ignored.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Format","id":"147","title":"Batch Format"},"148":{"body":"The above primarily describes the general encodings used in L2 chain derivation, primarily how batches are encoded within batcher transactions . This section describes how the L2 chain is produced from the L1 batches using a pipeline architecture. A verifier may implement this differently, but must be semantically equivalent to not diverge from the L2 chain.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Architecture","id":"148","title":"Architecture"},"149":{"body":"Our architecture decomposes the derivation process into a pipeline made up of the following stages: L1 Traversal L1 Retrieval Frame Queue Channel Bank Channel Reader (Batch Decoding) Batch Queue Payload Attributes Derivation Engine Queue The data flows from the start (outer) of the pipeline towards the end (inner). From the innermost stage the data is pulled from the outermost stage. However, data is processed in reverse order. Meaning that if there is any data to be processed in the last stage, it will be processed first. Processing proceeds in \"steps\" that can be taken at each stage. We try to take as many steps as possible in the last (most inner) stage before taking any steps in its outer stage, etc. This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing the derivation pipeline. Each stage can maintain its own inner state as necessary. In particular, each stage maintains a L1 block reference (number + hash) to the latest L1 block such that all data originating from previous blocks has been fully processed, and the data from that block is being or has been processed. This allows the innermost stage to account for finalization of the L1 data-availability used to produce the L2 chain, to reflect in the L2 chain forkchoice when the L2 chain inputs become irreversible. Let's briefly describe each stage of the pipeline.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L2 Chain Derivation Pipeline","id":"149","title":"L2 Chain Derivation Pipeline"},"15":{"body":"Users are the general class of network participants who: Submit transactions through a Sequencer or by interacting with contracts on Ethereum. Query transaction data from interfaces operated by verifiers.","breadcrumbs":"Background » Users","id":"15","title":"Users"},"150":{"body":"In the L1 Traversal stage, we simply read the header of the next L1 block. In normal operations, these will be new L1 blocks as they get created, though we can also read old blocks while syncing, or in case of an L1 re-org . Upon traversal of the L1 block, the system configuration copy used by the L1 retrieval stage is updated, such that the batch-sender authentication is always accurate to the exact L1 block that is read by the stage.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Traversal","id":"150","title":"L1 Traversal"},"151":{"body":"In the L1 Retrieval stage, we read the block we get from the outer stage (L1 traversal), and extract data from its batcher transactions . A batcher transaction is one with the following properties: The to field is equal to the configured batcher inbox address. The sender, as recovered from the transaction signature (v, r, and s), is the batcher address loaded from the system config matching the L1 block of the data. Each batcher transaction is versioned and contains a series of channel frames to be read by the Frame Queue, see Batch Submission Wire Format . Each batcher transaction in the block is processed in the order they appear in the block by passing its calldata on to the next phase.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » L1 Retrieval","id":"151","title":"L1 Retrieval"},"152":{"body":"The Frame Queue buffers one data-transaction at a time, decoded into channel frames , to be consumed by the next stage. See Batcher transaction format and Frame format specifications.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Frame Queue","id":"152","title":"Frame Queue"},"153":{"body":"The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1 retrieval stage. A step in the channel bank stage tries to read data from channels that are \"ready\". Channels are currently fully buffered until read or dropped, streaming channels may be supported in a future version of the ChannelBank. To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels. Channels are recorded in FIFO order in a structure called the channel queue . A channel is added to the channel queue the first time a frame belonging to the channel is seen. Pruning After successfully inserting a new frame, the ChannelBank is pruned: channels are dropped in FIFO order, until total_size <= MAX_CHANNEL_BANK_SIZE, where: total_size is the sum of the sizes of each channel, which is the sum of all buffered frame data of the channel, with an additional frame-overhead of 200 bytes per frame. MAX_CHANNEL_BANK_SIZE is a protocol constant defined in the Protocol Parameters table . Timeouts The L1 origin that the channel was opened in is tracked with the channel as channel.open_l1_block, and determines the maximum span of L1 blocks that the channel data is retained for, before being pruned. A channel is timed out if: current_l1_block.number > channel.open_l1_block.number + CHANNEL_TIMEOUT, where: current_l1_block is the L1 origin that the stage is currently traversing. CHANNEL_TIMEOUT is a rollup-configurable, expressed in number of L1 blocks. New frames for timed-out channels are dropped instead of buffered. Reading Upon reading, while the first opened channel is timed-out, remove it from the channel-bank. Prior to the Canyon network upgrade, once the first opened channel, if any, is not timed-out and is ready, then it is read and removed from the channel-bank. After the Canyon network upgrade, the entire channel bank is scanned in FIFO order (by open time) & the first ready (i.e. not timed-out) channel will be returned. The canyon behavior will activate when frames from a L1 block whose timestamp is greater than or equal to the canyon time first enter the channel queue. A channel is ready if: The channel is closed The channel has a contiguous sequence of frames until the closing frame If no channel is ready, the next frame is read and ingested into the channel bank. Loading frames When a channel ID referenced by a frame is not already present in the Channel Bank, a new channel is opened, tagged with the current L1 block, and appended to the channel-queue. Frame insertion conditions: New frames matching timed-out channels that have not yet been pruned from the channel-bank are dropped. Duplicate frames (by frame number) for frames that have not been pruned from the channel-bank are dropped. Duplicate closes (new frame is_last == 1, but the channel has already seen a closing frame and has not yet been pruned from the channel-bank) are dropped. If a frame is closing (is_last == 1) any existing higher-numbered frames are removed from the channel. Note that while this allows channel IDs to be reused once they have been pruned from the channel-bank, it is recommended that batcher implementations use unique channel IDs.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Bank","id":"153","title":"Channel Bank"},"154":{"body":"In this stage, we decompress the channel we pull from the last stage, and then parse batches from the decompressed byte stream. See Channel Format and Batch Format for decompression and decoding specification.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Channel Reader (Batch Decoding)","id":"154","title":"Channel Reader (Batch Decoding)"},"155":{"body":"During the Batch Buffering stage, we reorder batches by their timestamps. If batches are missing for some time slots and a valid batch with a higher timestamp exists, this stage also generates empty batches to fill the gaps. Batches are pushed to the next stage whenever there is one sequential batch directly following the timestamp of the current safe L2 head (the last block that can be derived from the canonical L1 chain). The parent hash of the batch must also match the hash of the current safe L2 head. Note that the presence of any gaps in the batches derived from L1 means that this stage will need to buffer for a whole sequencing window before it can generate empty batches (because the missing batch(es) could have data in the last L1 block of the window in the worst case). A batch can have 4 different forms of validity: drop: the batch is invalid, and will always be in the future, unless we reorg. It can be removed from the buffer. accept: the batch is valid and should be processed. undecided: we are lacking L1 information until we can proceed batch filtering. future: the batch may be valid, but cannot be processed yet and should be checked again later. The batches are processed in order of the inclusion on L1: if multiple batches can be accept-ed the first is applied. An implementation can defer future batches a later derivation step to reduce validation work. The batches validity is derived as follows: Definitions: batch as defined in the Batch format section . epoch = safe_l2_head.l1_origin a L1 origin coupled to the batch, with properties: number (L1 block number), hash (L1 block hash), and timestamp (L1 block timestamp). inclusion_block_number is the L1 block number when batch was first fully derived, i.e. decoded and output by the previous stage. next_timestamp = safe_l2_head.timestamp + block_time is the expected L2 timestamp the next batch should have, see block time information . next_epoch may not be known yet, but would be the L1 block after epoch if available. batch_origin is either epoch or next_epoch, depending on validation. Note that processing of a batch can be deferred until batch.timestamp <= next_timestamp, since future batches will have to be retained anyway. Rules, in validation order: batch.timestamp > next_timestamp -> future: i.e. the batch must be ready to process. batch.timestamp < next_timestamp -> drop: i.e. the batch must not be too old. batch.parent_hash != safe_l2_head.hash -> drop: i.e. the parent hash must be equal to the L2 safe head block hash. batch.epoch_num + sequence_window_size < inclusion_block_number -> drop: i.e. the batch must be included timely. batch.epoch_num < epoch.number -> drop: i.e. the batch origin is not older than that of the L2 safe head. batch.epoch_num == epoch.number: define batch_origin as epoch. batch.epoch_num == epoch.number+1: If next_epoch is not known -> undecided: i.e. a batch that changes the L1 origin cannot be processed until we have the L1 origin data. If known, then define batch_origin as next_epoch batch.epoch_num > epoch.number+1 -> drop: i.e. the L1 origin cannot change by more than one L1 block per L2 block. batch.epoch_hash != batch_origin.hash -> drop: i.e. a batch must reference a canonical L1 origin, to prevent batches from being replayed onto unexpected L1 chains. batch.timestamp < batch_origin.time -> drop: enforce the min L2 timestamp rule. batch.timestamp > batch_origin.time + max_sequencer_drift: enforce the L2 timestamp drift rule, but with exceptions to preserve above min L2 timestamp invariant: len(batch.transactions) == 0: epoch.number == batch.epoch_num: this implies the batch does not already advance the L1 origin, and must thus be checked against next_epoch. If next_epoch is not known -> undecided: without the next L1 origin we cannot yet determine if time invariant could have been kept. If batch.timestamp >= next_epoch.time -> drop: the batch could have adopted the next L1 origin without breaking the L2 time >= L1 time invariant. len(batch.transactions) > 0: -> drop: when exceeding the sequencer time drift, never allow the sequencer to include transactions. batch.transactions: drop if the batch.transactions list contains a transaction that is invalid or derived by other means exclusively: any transaction that is empty (zero length byte string) any deposited transactions (identified by the transaction type prefix byte) If no batch can be accept-ed, and the stage has completed buffering of all batches that can fully be read from the L1 block at height epoch.number + sequence_window_size, and the next_epoch is available, then an empty batch can be derived with the following properties: parent_hash = safe_l2_head.hash timestamp = next_timestamp transactions is empty, i.e. no sequencer transactions. Deposited transactions may be added in the next stage. If next_timestamp < next_epoch.time: the current L1 origin is repeated, to preserve the L2 time invariant. epoch_num = epoch.number epoch_hash = epoch.hash If the batch is the first batch of the epoch, that epoch is used instead of advancing the epoch to ensure that there is at least one L2 block per epoch. epoch_num = epoch.number epoch_hash = epoch.hash Otherwise, epoch_num = next_epoch.number epoch_hash = next_epoch.hash","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Batch Queue","id":"155","title":"Batch Queue"},"156":{"body":"In the Payload Attributes Derivation stage, we convert the batches we get from the previous stage into instances of the PayloadAttributes structure. Such a structure encodes the transactions that need to figure into a block, as well as other block inputs (timestamp, fee recipient, etc). Payload attributes derivation is detailed in the section Deriving Payload Attributes section below. This stage maintains its own copy of the system configuration , independent of the L1 retrieval stage. The system configuration is updated with L1 log events whenever the L1 epoch referenced by the batch input changes.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Payload Attributes Derivation","id":"156","title":"Payload Attributes Derivation"},"157":{"body":"In the Engine Queue stage, the previously derived PayloadAttributes structures are buffered and sent to the execution engine to be executed and converted into a proper L2 block. The stage maintains references to three L2 blocks: The finalized L2 head : everything up to and including this block can be fully derived from the finalized (i.e. canonical and forever irreversible) part of the L1 chain. The safe L2 head : everything up to and including this block can be fully derived from the currently canonical L1 chain. The unsafe L2 head : blocks between the safe and unsafe heads are unsafe blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer mode) or from unsafe sync to the sequencer (in validator mode). This is also known as the \"latest\" head. Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references from which L1 blocks each was derived. This history does not have to be complete, but enables later L1 finality signals to be translated into L2 finality. Engine API usage To interact with the engine, the execution engine API is used, with the following JSON-RPC methods: Bedrock, Canyon, Delta: API Usage engine_forkchoiceUpdatedV2 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV2 — retrieves a previously requested execution payload build. engine_newPayloadV2 — executes an execution payload to create a block. Ecotone: API Usage engine_forkchoiceUpdatedV3 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and instructs the engine to start building an execution payload if the payload attributes parameter is not null. engine_getPayloadV3 — retrieves a previously requested execution payload build. engine_newPayload engine_newPayloadV2 — executes a Bedrock/Canyon/Delta execution payload to create a block. engine_newPayloadV3 — executes an Ecotone execution payload to create a block. The current version of op-node uses the v3 Engine API RPC methods as well as engine_newPayloadV2, due to engine_newPayloadV3 only supporting Ecotone execution payloads. Both engine_forkchoiceUpdatedV3 and engine_getPayloadV3 are backwards compatible with Bedrock, Canyon & Delta payloads. Prior versions of op-node used v2 and v1 methods. The execution payload is an object of type ExecutionPayloadV3 . The ExecutionPayload has the following requirements: Bedrock The withdrawals field MUST be nil The blob gas used field MUST be nil The blob gas limit field MUST be nil Canyon, Delta The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be nil The blob gas limit field MUST be nil Ecotone The withdrawals field MUST be non-nil The withdrawals field MUST be an empty list The blob gas used field MUST be 0 The blob gas limit field MUST be 0 Forkchoice synchronization If there are any forkchoice updates to be applied, before additional inputs are derived or processed, then these are applied to the engine first. This synchronization may happen when: A L1 finality signal finalizes one or more L2 blocks: updating the \"finalized\" L2 block. A successful consolidation of unsafe L2 blocks: updating the \"safe\" L2 block. The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state. The new forkchoice state is applied by calling fork choice updated on the engine API. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. L1-consolidation: payload attributes matching If the unsafe head is ahead of the safe head, then consolidation is attempted, verifying that existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data. During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If the payload attributes match this oldest unsafe L2 block, then that block can be considered \"safe\" and becomes the new safe head. The following fields of the derived L2 payload attributes are checked for equality with the L2 block: Bedrock, Canyon, Delta, Ecotone Blocks parent_hash timestamp randao fee_recipient transactions_list (first length, then equality of each of the encoded transactions, including deposits) gas_limit Canyon, Delta, Ecotone Blocks withdrawals (first presence, then length, then equality of each of the encoded withdrawals) Ecotone Blocks parent_beacon_block_root If consolidation succeeds, the forkchoice change will synchronize as described in the section above. If consolidation fails, the L2 payload attributes will be processed immediately as described in the section below. The payload attributes are chosen in favor of the previous unsafe L2 block, creating an L2 chain reorg on top of the current safe block. Immediately processing the new alternative attributes enables execution engines like go-ethereum to enact the change, as linear rewinds of the tip of the chain may not be supported. L1-sync: payload attributes processing If the safe and unsafe L2 heads are identical (whether because of failed consolidation or not), we send the L2 payload attributes to the execution engine to be constructed into a proper L2 block. This L2 block will then become both the new L2 safe and unsafe head. If a payload attributes created from a batch cannot be inserted into the chain because of a validation error (i.e. there was an invalid transaction or state transition in the block) the batch should be dropped & the safe head should not be advanced. The engine queue will attempt to use the next batch for that timestamp from the batch queue. If no valid batch is found, the rollup node will create a deposit only batch which should always pass validation because deposits are always valid. Interaction with the execution engine via the execution engine API is detailed in the Communication with the Execution Engine section. The payload attributes are then processed with a sequence of: Engine: Fork choice updated with current forkchoice state of the stage, and the attributes to start block building. Non-deterministic sources, like the tx-pool, must be disabled to reconstruct the expected block. Engine: Get Payload to retrieve the payload, by the payload-ID in the result of the previous step. Engine: New Payload to import the new payload into the execution engine. Engine: Fork Choice Updated to make the new payload canonical, now with a change of both safe and unsafe fields to refer to the payload, and no payload attributes. Engine API Error handling: On RPC-type errors the payload attributes processing should be re-attempted in a future step. On payload processing errors the attributes must be dropped, and the forkchoice state must be left unchanged. Eventually the derivation pipeline will produce alternative payload attributes, with or without batches. If the payload attributes only contained deposits, then it is a critical derivation error if these are invalid. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state. Processing unsafe payload attributes If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as an \"unsafe\" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the user to see the head of the L2 chain faster than the L1 may confirm the L2 batches. To process unsafe payloads, the payload must: Have a block number higher than the current safe L2 head. The safe L2 head may only be reorged out due to L1 reorgs. Have a parent blockhash that matches the current unsafe L2 head. This prevents the execution engine individually syncing a larger gap in the unsafe L2 chain. This prevents unsafe L2 blocks from reorging other previously validated L2 blocks. This check may change in the future versions to adopt e.g. the L1 snap-sync protocol. The payload is then processed with a sequence of: Bedrock/Canyon/Delta Payloads engine_newPayloadV2: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV2: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Ecotone Payloads engine_newPayloadV3: process the payload. It does not become canonical yet. engine_forkchoiceUpdatedV3: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads. Engine API Error handling: On RPC-type errors the payload processing should be re-attempted in a future step. On payload processing errors the payload must be dropped, and not be marked as canonical. On forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Engine Queue","id":"157","title":"Engine Queue"},"158":{"body":"It is possible to reset the pipeline, for instance if we detect an L1 reorg (reorganization) . This enables the rollup node to handle L1 chain reorg events. Resetting will recover the pipeline into a state that produces the same outputs as a full L2 derivation process, but starting from an existing L2 chain that is traversed back just enough to reconcile with the current L1 chain. Note that this algorithm covers several important use-cases: Initialize the pipeline without starting from 0, e.g. when the rollup node restarts with an existing engine instance. Recover the pipeline if it becomes inconsistent with the execution engine chain, e.g. when the engine syncs/changes. Recover the pipeline when the L1 chain reorganizes, e.g. a late L1 block is orphaned, or a larger attestation failure. Initialize the pipeline to derive a disputed L2 block with prior L1 and L2 history inside a fault-proof program. Handling these cases also means a node can be configured to eagerly sync L1 data with 0 confirmations, as it can undo the changes if the L1 later does recognize the data as canonical, enabling safe low-latency usage. The Engine Queue is first reset, to determine the L1 and L2 starting points to continue derivation from. After this, the other stages are reset independent of each other. Finding the sync starting point To find the starting point, there are several steps, relative to the head of the chain traversing back: Find the current L2 forkchoice state If no finalized block can be found, start at the Bedrock genesis block. If no safe block can be found, fallback to the finalized block. The unsafe block should always be available and consistent with the above (it may not be in rare engine-corruption recovery cases, this is being reviewed). Find the first L2 block with plausible L1 reference to be the new unsafe starting point, starting from previous unsafe, back to finalized and no further. Plausible iff: the L1 origin of the L2 block is known and canonical, or unknown and has a block-number ahead of L1. Find the first L2 block with an L1 reference older than the sequencing window, to be the new safe starting point, starting at the above plausible unsafe head, back to finalized and no further. If at any point the L1 origin is known but not canonical, the unsafe head is revised to parent of the current. The highest L2 block with known canonical L1 origin is remembered as highest. If at any point the L1 origin in the block is corrupt w.r.t. derivation rules, then error. Corruption includes: Inconsistent L1 origin block number or parent-hash with parent L1 origin Inconsistent L1 sequence number (always changes to 0 for a L1 origin change, or increments by 1 if not) If the L1 origin of the L2 block n is older than the L1 origin of highest by more than a sequence window, and n.sequence_number == 0, then the parent L2 block of n will be the safe starting point. The finalized L2 block persists as the finalized starting point. Find the first L2 block with an L1 reference older than the channel-timeout The L1 origin referenced by this block which we call l2base will be the base for the L2 pipeline derivation: By starting here, the stages can buffer any necessary data, while dropping incomplete derivation outputs until L1 traversal has caught up with the actual L2 safe head. While traversing back the L2 chain, an implementation may sanity-check that the starting point is never set too far back compared to the existing forkchoice state, to avoid an intensive reorg because of misconfiguration. Implementers note: step 1-4 are known as FindL2Heads. Step 5 is currently part of the Engine Queue reset. This may change to isolate the starting-point search from the bare reset logic. Resetting derivation stages L1 Traversal: start at L1 base as first block to be pulled by next stage. L1 Retrieval: empty previous data, and fetch the base L1 data, or defer the fetching work to a later pipeline step. Frame Queue: empty the queue. Channel Bank: empty the channel bank. Channel Reader: reset any batch decoding state. Batch Queue: empty the batch queue, use base as initial L1 point of reference. Payload Attributes Derivation: empty any batch/attributes state. Engine Queue: Initialize L2 forkchoice state with syncing start point state. (finalized/safe/unsafe) Initialize the L1 point of reference of the stage to base. Require a forkchoice update as first task Reset any finality data Where necessary, stages starting at base can initialize their system-config from data encoded in the l2base block. About reorgs Post-Merge Note that post- merge , the depth of reorgs will be bounded by the L1 finality delay (2 L1 beacon epochs, or approximately 13 minutes, unless more than 1/3 of the network consistently disagrees). New L1 blocks may be finalized every L1 beacon epoch (approximately 6.4 minutes), and depending on these finality-signals and batch-inclusion, the derived L2 chain will become irreversible as well. Note that this form of finalization only affects inputs, and nodes can then subjectively say the chain is irreversible, by reproducing the chain from these irreversible inputs and the set protocol rules and parameters. This is however completely unrelated to the outputs posted on L1, which require a form of proof like a fault-proof or zk-proof to finalize. Optimistic-rollup outputs like withdrawals on L1 are only labeled \"finalized\" after passing a week without dispute (fault proof challenge window), a name-collision with the proof-of-stake finalization.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Resetting the Pipeline","id":"158","title":"Resetting the Pipeline"},"159":{"body":"For every L2 block derived from L1 data, we need to build payload attributes , represented by an expanded version of the PayloadAttributesV2 object, which includes additional transactions and noTxPool fields. This process happens during the payloads-attributes queue ran by a verifier node, as well as during block-production ran by a sequencer node (the sequencer may enable the tx-pool usage if the transactions are batch-submitted).","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving Payload Attributes","id":"159","title":"Deriving Payload Attributes"},"16":{"body":"Sequencers fill the role of the block producer on an OP Stack chain. Chains may have a single Sequencer or may choose to utilize some consensus protocol that coordinates multiple Sequencers. The OP Stack currently officially only supports a single active Sequencer at any given time. In general, specifications may use the term \"the Sequencer\" as a stand-in for either a single Sequencer or a consensus protocol of multiple Sequencers. The Sequencer: Accepts transactions directly from Users. Observes \"deposit\" transactions generated on Ethereum. Consolidates both transaction streams into ordered L2 blocks. Submits information to L1 that is sufficient to fully reproduce those L2 blocks. Provides real-time access to pending L2 blocks that have not yet been confirmed on L1. The Sequencer serves an important role for the operation of an L2 chain but is not a trusted actor. The Sequencer is generally responsible for improving the user experience by ordering transactions much more quickly and cheaply than would currently be possible if users were to submit all transactions directly to L1.","breadcrumbs":"Background » Sequencers","id":"16","title":"Sequencers"},"160":{"body":"For each L2 block to be created by the sequencer, we start from a sequencer batch matching the target L2 block number. This could potentially be an empty auto-generated batch, if the L1 chain did not include a batch for the target L2 block number. Remember that the batch includes a sequencing epoch number, an L2 timestamp, and a transaction list. This block is part of a sequencing epoch , whose number matches that of an L1 block (its L1 origin ). This L1 block is used to derive L1 attributes and (for the first L2 block in the epoch) user deposits. Therefore, a PayloadAttributesV2 object must include the following transactions: one or more deposited transactions , of two kinds: a single L1 attributes deposited transaction , derived from the L1 origin. for the first L2 block in the epoch, zero or more user-deposited transactions , derived from the receipts of the L1 origin. zero or more network upgrade automation transactions : special transactions to perform network upgrades. zero or more sequenced transactions : regular transactions signed by L2 users, included in the sequencer batch. Transactions must appear in this order in the payload attributes. The L1 attributes are read from the L1 block header, while deposits are read from the L1 block's receipts . Refer to the deposit contract specification for details on how deposits are encoded as log entries.","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Deriving the Transaction List","id":"160","title":"Deriving the Transaction List"},"161":{"body":"Some network upgrades require automated contract changes or deployments at specific blocks. To automate these, without adding persistent changes to the execution-layer, special transactions may be inserted as part of the derivation process. Ecotone The Ecotone hardfork activation block contains the following transactions, in this order: L1 Attributes Transaction, using the pre-Ecotone setL1BlockValues User deposits from L1 Network Upgrade Transactions L1Block deployment GasPriceOracle deployment Update L1Block Proxy ERC-1967 Implementation Slot Update GasPriceOracle Proxy ERC-1967 Implementation Slot GasPriceOracle Enable Ecotone Beacon block roots contract deployment (EIP-4788) To not modify or interrupt the system behavior around gas computation, this block will not include any sequenced transactions by setting noTxPool: true. L1Block Deployment The L1Block contract is upgraded to process the new Ecotone L1-data-fee parameters and L1 blob base-fee. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000000 to: null mint: 0 value: 0 gasLimit: 375,000 data: 0x60806040523480156100105... ( full bytecode ) sourceHash: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Deployment\" This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000000\nComputed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Deployment\"))\n# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json This transaction MUST deploy a contract with the following code hash 0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd. GasPriceOracle Deployment The GasPriceOracle contract is upgraded to support the new Ecotone L1-data-fee parameters. Post fork this contract will use the blob base fee to compute the gas price for L1-data-fee transactions. A deposit transaction is derived with the following attributes: from: 0x4210000000000000000000000000000000000001 to: null, mint: 0 value: 0 gasLimit: 1,000,000 data: 0x60806040523480156100... ( full bytecode ) sourceHash: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Deployment\" This results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A, to verify: cast compute-address --nonce=0 0x4210000000000000000000000000000000000001\nComputed Address: 0xb528D11cC114E026F138fE568744c6D45ce6Da7A Verify sourceHash: ❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Deployment\"))\n# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42 Verify data: git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json This transaction MUST deploy a contract with the following code hash 0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5. L1Block Proxy Update This transaction updates the L1Block Proxy ERC-1967 implementation slot to point to the new L1Block deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x4200000000000000000000000000000000000015 (L1Block Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff sourceHash: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)\n0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Proxy Update\"))\n# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc GasPriceOracle Proxy Update This transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle deployment. A deposit transaction is derived with the following attributes: from: 0x0000000000000000000000000000000000000000 to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 50,000 data: 0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a sourceHash: 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: Gas Price Oracle Proxy Update\" Verify data: cast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)\n0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Proxy Update\"))\n# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a GasPriceOracle Enable Ecotone This transaction informs the GasPriceOracle to start using the Ecotone gas calculation formula. A deposit transaction is derived with the following attributes: from: 0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 (Depositer Account) to: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy) mint: 0 value: 0 gasLimit: 80,000 data: 0x22b90ab3 sourceHash: 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93, computed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Set Ecotone\" Verify data: cast sig \"setEcotone()\"\n0x22b90ab3 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Set Ecotone\"))\n# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93 Beacon block roots contract deployment (EIP-4788) EIP-4788 introduces a \"Beacon block roots\" contract, that processes and exposes the beacon-block-root values. at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02. For deployment, EIP-4788 defines a pre- EIP-155 legacy transaction, sent from a key that is derived such that the transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code. However, this type of transaction requires manual deployment and gas-payments. And since the processing is an integral part of the chain processing, and has to be repeated for every OP-Stack chain, the deployment is approached differently here. Some chains may already have a user-submitted instance of the EIP-4788 transaction. This is cryptographically guaranteed to be correct, but may result in the upgrade transaction deploying a second contract, with the next nonce. The result of this deployment can be ignored. A Deposit transaction is derived with the following attributes: from: 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875, as specified in the EIP. to: null mint: 0 value: 0 gasLimit: 0x3d090, as specified in the EIP. isCreation: true data: 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500 isSystemTx: false, as per the Regolith upgrade, even the system-generated transactions spend gas. sourceHash: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c, computed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: beacon block roots contract deployment\" The contract address upon deployment is computed as rlp([sender, nonce]), which will equal: BEACON_ROOTS_ADDRESS if deployed a different address (0xE3aE1Ae551eeEda337c0BfF6C4c7cbA98dce353B) if nonce = 1: when a user already submitted the EIP transaction before the upgrade. Verify BEACON_ROOTS_ADDRESS: cast compute-address --nonce=0 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875\n# Computed Address: 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02 Verify sourceHash: cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: beacon block roots contract deployment\"))\n# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Network upgrade automation transactions","id":"161","title":"Network upgrade automation transactions"},"162":{"body":"After deriving the transactions list, the rollup node constructs a PayloadAttributesV2 as follows: timestamp is set to the batch's timestamp. random is set to the prev_randao L1 block attribute. suggestedFeeRecipient is set to the Sequencer Fee Vault address. See Fee Vaults specification. transactions is the array of the derived transactions: deposited transactions and sequenced transactions, all encoded with EIP-2718 . noTxPool is set to true, to use the exact above transactions list when constructing the block. gasLimit is set to the current gasLimit value in the system configuration of this payload. withdrawals is set to nil prior to Canyon and an empty array after Canyon","breadcrumbs":"OP Stack Protocol » Clients » Rollup Node » Derivation » Building Individual Payload Attributes","id":"162","title":"Building Individual Payload Attributes"},"163":{"body":"Table of Contents Overview","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Batch Submitter","id":"163","title":"Batch Submitter"},"164":{"body":"The batch submitter, also referred to as the batcher, is the entity submitting the L2 sequencer data to L1, to make it available for verifiers. The format of the data transactions is defined in the derivation spec : the data is constructed from L2 blocks in the reverse order as it is derived from data into L2 blocks. The timing, operation and transaction signing is implementation-specific: any data can be submitted at any time, but only the data that matches the derivation spec rules will be valid from the verifier perspective. The most minimal batcher implementation can be defined as a loop of the following operations: See if the unsafe L2 block number is past the safe block number: unsafe data needs to be submitted. Iterate over all unsafe L2 blocks, skip any that were previously submitted. Open a channel, buffer all the L2 block data to be submitted, while applying the encoding and compression as defined in the derivation spec . Pull frames from the channel to fill data transactions with, until the channel is empty. Submit the data transactions to L1 The L2 view of safe/unsafe does not instantly update after data is submitted, nor when it gets confirmed on L1, so special care may have to be taken to not duplicate data submissions.","breadcrumbs":"OP Stack Protocol » Clients » Batch Submitter » Overview","id":"164","title":"Overview"},"165":{"body":"Table of Contents Overview Pre-image Oracle Pre-image key types Type 0: Zero key Type 1: Local key Type 2: Global keccak256 key Type 3: Global generic key Type 4: Global SHA2-256 key Type 5: Global EIP-4844 Point-evaluation key Type 6: Global Precompile key Type 7-128: reserved range Type 129-255: application usage Bootstrapping Hinting Pre-image communication Fault Proof Program Prologue Main content Epilogue Pre-image hinting routes l1-block-header l1-transactions l1-receipts l1-precompile l2-block-header l2-transactions l2-code l2-state-node l2-output Precompile Accelerators Fault Proof VM Fault Proof Interactive Dispute Game","breadcrumbs":"OP Stack Protocol » Fault Proof » Fault Proof","id":"165","title":"Fault Proof"},"166":{"body":"A fault proof, also known as fraud proof or interactive game, consists of 3 components: Program : given a commitment to all rollup inputs (L1 data) and the dispute, verify the dispute statelessly. VM : given a stateless program and its inputs, trace any instruction step, and prove it on L1. Interactive Dispute Game : bisect a dispute down to a single instruction, and resolve the base-case using the VM. Each of these 3 components may have different implementations, which can be combined into different proof stacks, and contribute to proof diversity when resolving a dispute. \"Stateless execution\" of the program, and its individual instructions, refers to reproducing the exact same computation by authenticating the inputs with a Pre-image Oracle . Diagram of Program and VM architecture","breadcrumbs":"OP Stack Protocol » Fault Proof » Overview","id":"166","title":"Overview"},"167":{"body":"The pre-image oracle is the only form of communication between the Program (in the Client role) and the VM (in the Server role). The program uses the pre-image oracle to query any input data that is understood to be available to the user: The initial inputs to bootstrap the program. See Bootstrapping . External data not already part of the program code. See Pre-image hinting routes . The communication happens over a simple request-response wire protocol, see Pre-image communication .","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image Oracle","id":"167","title":"Pre-image Oracle"},"168":{"body":"Pre-images are identified by a bytes32 type-prefixed key: The first byte identifies the type of request. The remaining 31 bytes identify the pre-image key. Type 0: Zero key The zero prefix is illegal. This ensures all pre-image keys are non-zero, enabling storage lookup optimizations and avoiding easy mistakes with invalid zeroed keys in the EVM. Type 1: Local key Information specific to the dispute: the remainder of the key may be an index, a string, a hash, etc. Only the contract(s) managing this dispute instance may serve the value for this key: it is localized and context-dependent. This type of key is used for program bootstrapping, to identify the initial input arguments by index or name. Type 2: Global keccak256 key This type of key uses a global pre-image store contract, and is fully context-independent and permissionless. I.e. every key must have a single unique value, regardless of chain history or time. Using a global store reduces duplicate pre-image registration work, and avoids unnecessary contract redeployments per dispute. This global store contract should be non-upgradeable. Since keccak256 is a safe 32-byte hash input, the first byte is overwritten with a 2 to derive the key, while keeping the rest of the key \"readable\" (matching the original hash). Type 3: Global generic key Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments. This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:], where: x is a bytes32, which can be a hash of an arbitrary-length type of cryptographically secure commitment. sender is a bytes32 identifying the pre-image inserter address (left-padded to 32 bytes) This global store contract should be non-upgradeable. The global contract is permissionless: users can standardize around external contracts that verify pre-images (i.e. a specific sender will always be trusted for a specific kind of pre-image). The external contract verifies the pre-image before inserting it into the global store for usage by all fault proof VMs without requiring the VM or global store contract to be changed. Users may standardize around upgradeable external pre-image contracts, in case the implementation of the verification of the pre-image is expected to change. The store update function is update(x bytes32, offset uint64, span uint8, value bytes32): x is the bytes32 x that the pre-image key is computed with. Only part of the pre-image, starting at offset, and up to (incl.) 32 bytes span can be inserted at a time. Pre-images may have an undefined length (e.g. a stream), we only need to know how many bytes of value are usable. The key and offset will be hashed together to uniquely store the value and span, for later pre-image serving. This enables fault proof programs to adopt any new pre-image schemes without VM update or contract redeployment. It is up to the user to index the special pre-image values by this key scheme, as there is no way to revert it to the original commitment without knowing said commitment or value. Type 4: Global SHA2-256 key A SHA-256 pre-image. Key: the SHA-256 hash, with the first byte overwritten with the type byte: 4 ++ sha256(data)[1:]. Type 5: Global EIP-4844 Point-evaluation key An EIP-4844 point-evaluation. In an EIP-4844 blob, 4096 field elements represent the blob data. It verifies p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof. The value y is the pre-image. The value z is part of the key; the index of the point within the blob. The commitment is part of the key. Each element is proven with a point-evaluation. Key: 5 ++ keccak256(commitment ++ z)[1:], where: 5 is the type byte ++ is concatenation commitment is a bytes48, representing the KZG commitment. z is a big-endian uint256 Type 6: Global Precompile key A precompile result. It maps directly to precompiles on Ethereum. This preimage key can be used to avoid running expensive precompile operations in the program. Key: 6 ++ keccak256(precompile ++ input)[1:], where: 6 is the type byte ++ is concatenation precompile is the 20-byte address of the precompile contract input is the input to the precompile contract The result is identical to that of a call to the precompile contract, prefixed with a revert indicator: reverted ++ precompile_result. reverted is a 1-byte indicator with a 0 value if the precompile reverts for the given input, otherwise it's 1. Type 7-128: reserved range Range start and end both inclusive. This range of key types is reserved for future usage by the core protocol. E.g. version changes, contract migrations, chain-data, additional core features, etc. 128 specifically (1000 0000 in binary) is reserved for key-type length-extension (reducing the content part to 30 or less key bytes), if the need arises. Type 129-255: application usage This range of key types may be used by forks or customized versions of the fault proof protocol.","breadcrumbs":"OP Stack Protocol » Fault Proof » Pre-image key types","id":"168","title":"Pre-image key types"},"169":{"body":"Initial inputs are deterministic, but not necessarily singular or global: there may be multiple different disputes at the same time, each with its own disputed claims and L1 context. To bootstrap, the program requests the initial inputs from the VM, using pre-image key type 1. The VM is aware of the external context, and maps requested pre-image keys based on their type, i.e. a local lookup for type 1, or global one for 2, and optionally support other key-types.","breadcrumbs":"OP Stack Protocol » Fault Proof » Bootstrapping","id":"169","title":"Bootstrapping"},"17":{"body":"Verifiers download and execute the L2 state transition function independently of the Sequencer. Verifiers help to maintain the integrity of the network and serve blockchain data to Users. Verifiers generally: Download rollup data from L1 and the Sequencer. Use rollup data to execute the L2 state transition function. Serve rollup data and computed L2 state information to Users. Verifiers can also act as Proposers and/or Challengers who: Submit assertions about the state of the L2 to a smart contract on L1. Validate assertions made by other participants. Dispute invalid assertions made by other participants.","breadcrumbs":"Background » Verifiers","id":"17","title":"Verifiers"},"170":{"body":"There is one more form of optional communication between client and server: pre-image hinting. Hinting is optional, and is a no-op in a L1 VM implementation. The hint itself comes at very low cost onchain: the hint can be a single write sys-call, which is instant as the memory to write as hint does not actually need to be loaded as part of the onchain proof. Hinting allows the program, when generating a proof offchain, to instruct the VM what data it is interested in. The VM can choose to execute the requested hint at any time: either locally (for standard requests), or in a modular form by redirecting the hint to tooling that may come with the VM program. Hints do not have to be executed directly: they may first just be logged to show the intents of the program, and the latest hint may be buffered for lazy execution, or dropped entirely when in read-only mode (like onchain). When the pre-image oracle serves a request, and the request cannot be served from an existing collection of pre-images (e.g. a local pre-image cache) then the VM can execute the hint to retrieve the missing pre-image(s). It is the responsibility of the program to provide sufficient hinting for every pre-image request. Some hints may have to be repeated: the VM only has to execute the last hint when handling a missing pre-image. Note that hints may produce multiple pre-images: e.g. a hint for an ethereum block with transaction list may prepare pre-images for the header, each of the transactions, and the intermediate merkle-nodes that form the transactions-list Merkle Patricia Trie. Hinting is implemented with a request-acknowledgement wire-protocol over a blocking two-way stream: := := := big-endian uint32 # length of \n := byte sequence\n := 1-byte zero value The ack informs the client that the hint has been processed. Servers may respond to hints and pre-image (see below) requests asynchronously as they are on separate streams. To avoid requesting pre-images that are not yet fetched, clients should request the pre-image only after it has observed the hint acknowledgement.","breadcrumbs":"OP Stack Protocol » Fault Proof » Hinting","id":"170","title":"Hinting"},"171":{"body":"Pre-images are communicated with a minimal wire-protocol over a blocking two-way stream. This protocol can be implemented with blocking read/write syscalls. :=