Diff between 672eb5fe (main) and 000a3b56 (PR)

• aevo +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-optimium-superchain-opfp",
      "dataAvailability": [
        {
          "name": "Data is posted to EigenDA",
          "description": "Transactions roots are posted onchain and the full data is posted on EigenDA. The sequencer is publishing data to EigenDA v2. Since the DACert Verifier is not used, availability of the data is not verified against EigenDA operators, meaning that the Sequencer can single-handedly publish unavailable commitments. If EigenDA becomes unavailable, the sequencer falls back to Ethereum.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the sequencer posts an unavailable transaction root.",
              "isCritical": true
            },
            {
              "category": "Funds can be lost if",
              "text": "the data is not available on the external provider.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "EigenDA Docs - Overview",
              "url": "https://docs.eigenda.xyz/overview"
            },
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x253887577420Cb7e7418cD4d50147743c8041b28#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x5cccbd8b1Da78F94dE12D84CaCC494931f1b1E04#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 30m. Withdrawal inclusion can be proven before state root settlement, but a 1h period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 30m to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x5cccbd8b1Da78F94dE12D84CaCC494931f1b1E04#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x5cccbd8b1Da78F94dE12D84CaCC494931f1b1E04#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x5cccbd8b1Da78F94dE12D84CaCC494931f1b1E04#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 30m. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 10m, it generally gets extended by 10m with the exception of 20m right before depth 30, and 2s right before the last depth. The maximum clock extension that a top level claim can get is therefore 12h. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "warning": "The fault proof system is deployed but is not functional. The chain ID is not included in the op-program superchain registry, causing the dispute game to panic during execution. Security relies entirely on the permissioned proposer and challengers."
    }

• ancient +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-optimium-superchain-opfp",
      "dataAvailability": [
        {
          "name": "Data is posted to Celestia",
          "description": "Transactions roots are posted onchain and the full data is posted on Celestia.  Since the Blobstream bridge is not used, availability of the data is not verified against Celestia validators, meaning that the Sequencer can single-handedly publish unavailable roots. If Celestia becomes unavailable, the sequencer falls back to Ethereum.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the sequencer posts an unavailable transaction root.",
              "isCritical": true
            },
            {
              "category": "Funds can be lost if",
              "text": "the data is not available on the external provider.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Introducing Blobstream: streaming modular DA to Ethereum",
              "url": "https://blog.celestia.org/introducing-blobstream/"
            },
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xd5df46c580fD2FBdaEE751dc535E14295C0336F3#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "warning": "The fault proof system is deployed but is not functional. The chain ID is not included in the op-program superchain registry, causing the dispute game to panic during execution. Security relies entirely on the permissioned proposer and challengers."
    }

• arenaz +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x00f9BCEe08DCe4F0e7906c1f6cFb10c77802EEd0#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/arena-z.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/arena-z.json.zst).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• bobanetwork +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xfFF0000000000000000000000000000000000288#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 0s right before the last depth. The maximum clock extension that a top level claim can get is therefore 0s. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• celo +5 -0 Viewed

  • scalingTechnology +5 -0 Viewed

    {
      "architectureImage": "celo",
      "dataAvailability": [
        {
          "name": "Data is posted to EigenDA",
          "description": "Transactions roots are posted onchain and the full data is posted on EigenDA. The sequencer is publishing data to EigenDA v2. The DACert Verifier is used to verify attestations from the EigenDA operator set that the data is indeed available. If EigenDA becomes unavailable, the sequencer falls back to Ethereum.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the sequencer posts an unavailable transaction root.",
              "isCritical": true
            },
            {
              "category": "Funds can be lost if",
              "text": "the data is not available on the external provider.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "EigenDA Docs - Overview",
              "url": "https://docs.eigenda.xyz/overview"
            },
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xff00000000000000000000000000000000042220#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x2c431080Fc733E259654f3b91E39468d9A85Ac9b#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x2c431080Fc733E259654f3b91E39468d9A85Ac9b#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x2c431080Fc733E259654f3b91E39468d9A85Ac9b#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x2c431080Fc733E259654f3b91E39468d9A85Ac9b#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "categories": [
          {
            "title": "Fraud proofs",
            "description": "State roots are proposed by whitelisted proposers who create dispute games via the DisputeGameFactory by posting a bond of 0.01 ETH. Once created, the game enters a challenge period of 3d 12h during which whitelisted challengers can dispute the proposal by posting a bond of 0.01 ETH. If challenged, anyone can submit a ZK proof to prove the correct state within the proving period of 1d. After the challenge period passes without a successful challenge, or after a valid proof is submitted, anyone can resolve the game and finalize the state root.",
            "references": [
              {
                "url": "https://succinctlabs.github.io/op-succinct/fault_proofs/fault_proof_architecture.html",
                "title": "OP Succinct Lite architecture"
              },
              {
                "url": "https://docs.celo.org/home/protocol/challengers",
                "title": "Celo Challengers"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "the validity proof cryptography is broken or implemented incorrectly."
              },
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              },
              {
                "category": "Funds can be stolen if",
                "text": "the proposer routes proof verification through a malicious or faulty verifier."
              },
              {
                "category": "Funds can be frozen if",
                "text": "the permissioned proposer fails to publish state roots to the L1."
              }
            ]
          }
        ]
      }
    }

• corn +7 -1 Viewed

  • scalingTechnology +7 -1 Viewed

    {
      "architectureImage": "orbit-optimium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 1 out of 1.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            },
            {
              "category": "Users can be censored if",
              "text": "the committee restricts their access to the external data."
            }
          ],
          "references": [
            {
              "title": "Inside AnyTrust - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-anytrust"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://etherscan.io/address/0x6F2E7F9B5Db5e4e9B5B1181D2Eb0e4972500C324#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn't timely process a message. Only messages processed with a delay greater than 428424622y 1mo consume the buffer. The buffer is capped at 428424622y 1mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 428424622y 1mo.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 0.1 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 5d 14h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 5d 14h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 11d 4h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.1 ETH, level 2 requires a stake of 0.1 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• cyber +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp-preu16",
      "dataAvailability": [
        {
          "name": "Data required to compute fraud proof is published offchain without onchain attestations",
          "description": "The project relies on DA challenges for data availability. If a DA challenger finds that the data behind a tx data commitment is not available,\n      they can submit a challenge which requires locking a bond within 12h. A challenge can be resolved by publishing the preimage data within an additional 12h.\n      In such a case, a portion of the challenger bond is burned, with the exact amount estimated as the cost incurred by the resolver to publish the full data,\n      meaning that the resolver and challenger will approximately lose the same amount of funds. The system is not secure if the malicious sequencer is able to outspend the altruistic challengers. If instead, after a challenge, the preimage data is not published, the chain reorgs to the last fully derivable state. This mechanism fully depends on the derivation rule of the L2 node and can only be verified in its source code, which [can be reviewed here](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.4).",
          "references": [
            {
              "title": "OP Plasma specification",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md"
            },
            {
              "title": "Universal Plasma and DA Challenges - Ethresear.ch",
              "url": "https://ethresear.ch/t/universal-plasma-and-da-challenges/18629"
            },
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xfF00000000000000000000000000000000001d88#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
            }
          ],
          "risks": [
            {
              "category": "Funds can be stolen if",
              "text": "the sequencer is malicious and is able to economically outspend the altruistic challengers."
            },
            {
              "category": "Funds can be stolen if",
              "text": "there is no challenger willing to challenge unavailable data commitments."
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• ethereal +7 -1 Viewed

  • scalingTechnology +7 -1 Viewed

    {
      "architectureImage": "ethereal",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 1 out of 1.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            },
            {
              "category": "Users can be censored if",
              "text": "the committee restricts their access to the external data."
            }
          ],
          "references": [
            {
              "title": "Inside AnyTrust - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-anytrust"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://arbiscan.io/address/0xC08A4543b011fd4f1EfC9e26521F4e157433b3b1#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn't timely process a message. Only messages processed with a delay greater than 428424622y 1mo consume the buffer. The buffer is capped at 428424622y 1mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 428424622y 1mo.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 0.1 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 5d 14h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 5d 14h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 11d 4h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.1 ETH, level 2 requires a stake of 0.1 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• ethereum +5 -0 Viewed

  • daBridge +5 -0 Viewed

    {
      "daLayer": "ethereum",
      "name": "Enshrined Bridge",
      "risks": {
        "daBridge": {
          "value": "Enshrined",
          "sentiment": "good",
          "description": "Rollup users have access to all the data, as it is posted onchain on the consensus layer. On the execution layer, the rollup relies on blob data commitment (versioned hashes), which are accessible through the BLOBHASH opcode. \nThe rollup smart contracts can use these blob commitments during state transition validation to reference blobs during proof verification, without requiring direct access to the raw blob data.\n      "
        },
        "callout": "Unlike non-enshrined DA bridges, it does not place any honesty\nassumption on an external committee that provides data availability\nattestations to the DA bridge. From the rollup perspective,\nEthereum's canonical chain cannot contain unavailable data\ncommitments as full nodes self-verify the data availability of each\nblock, discarding blocks with unavailable data. The rollup state\nvalidating bridge has access to all the data, as it is posted on chain."
      },
      "technology": {
        "description": "## Enshrined Bridge\nThe DA bridge on Ethereum is enshrined, meaning that blob data is directly accessible on the consensus layer, with data availability guaranteed by the network's inherent consensus rules. \nIf a block contains unavailable data, full nodes will reject it, causing the chain to fork away from that block. This ensures data availability without requiring additional trust assumptions. \nIn contrast, external DA providers must rely on data availability attestations from the external validator set, introducing an extra layer of trust on the majority of validators."
      },
      "usedIn": [
        {
          "id": "abstract",
          "name": "Abstract",
          "slug": "abstract"
        },
        {
          "id": "adi",
          "name": "ADI Chain",
          "slug": "adi"
        },
        {
          "id": "arbitrum",
          "name": "Arbitrum One",
          "slug": "arbitrum"
        },
        {
          "id": "aztecnetwork",
          "name": "Aztec Network",
          "slug": "aztecnetwork"
        },
        {
          "id": "base",
          "name": "Base Chain",
          "slug": "base"
        },
        {
          "id": "blast",
          "name": "Blast",
          "slug": "blast"
        },
        {
          "id": "bob",
          "name": "BOB",
          "slug": "bob"
        },
        {
          "id": "bobanetwork",
          "name": "Boba Network",
          "slug": "bobanetwork"
        },
        {
          "id": "cartesi-prt-honeypot-v2",
          "name": "Cartesi PRT Honeypot v2",
          "slug": "cartesi-prt-honeypot-v2"
        },
        {
          "id": "dbk",
          "name": "DeBank Chain",
          "slug": "dbk"
        },
        {
          "id": "deri",
          "name": "Deri",
          "slug": "deri"
        },
        {
          "id": "ethscriptions",
          "name": "Ethscriptions",
          "slug": "ethscriptions"
        },
        {
          "id": "facet",
          "name": "Facet",
          "slug": "facet"
        },
        {
          "id": "fluent",
          "name": "Fluent",
          "slug": "fluent"
        },
        {
          "id": "forknet",
          "name": "Forknet",
          "slug": "forknet"
        },
        {
          "id": "hashkey",
          "name": "HashKey Chain",
          "slug": "hashkey"
        },
        {
          "id": "hemi",
          "name": "Hemi",
          "slug": "hemi"
        },
        {
          "id": "ink",
          "name": "Ink",
          "slug": "ink"
        },
        {
          "id": "katana",
          "name": "Katana",
          "slug": "katana"
        },
        {
          "id": "lighter",
          "name": "Lighter",
          "slug": "lighter"
        },
        {
          "id": "linea",
          "name": "Linea",
          "slug": "linea"
        },
        {
          "id": "lisk",
          "name": "Lisk",
          "slug": "lisk"
        },
        {
          "id": "mantle",
          "name": "Mantle",
          "slug": "mantle"
        },
        {
          "id": "metal",
          "name": "Metal",
          "slug": "metal"
        },
        {
          "id": "metis",
          "name": "Metis Andromeda",
          "slug": "metis"
        },
        {
          "id": "mode",
          "name": "Mode Network",
          "slug": "mode"
        },
        {
          "id": "morph",
          "name": "Morph",
          "slug": "morph"
        },
        {
          "id": "optimism",
          "name": "OP Mainnet",
          "slug": "op-mainnet"
        },
        {
          "id": "phala",
          "name": "Phala",
          "slug": "phala"
        },
        {
          "id": "r0ar",
          "name": "R0ar",
          "slug": "r0ar"
        },
        {
          "id": "race",
          "name": "Race Network",
          "slug": "race"
        },
        {
          "id": "robinhood",
          "name": "Robinhood Chain",
          "slug": "robinhood"
        },
        {
          "id": "scroll",
          "name": "Scroll",
          "slug": "scroll"
        },
        {
          "id": "shape",
          "name": "Shape",
          "slug": "shape"
        },
        {
          "id": "soneium",
          "name": "Soneium",
          "slug": "soneium"
        },
        {
          "id": "starknet",
          "name": "Starknet",
          "slug": "starknet"
        },
        {
          "id": "superseed",
          "name": "Superseed",
          "slug": "superseed"
        },
        {
          "id": "swan",
          "name": "Swan Chain",
          "slug": "swan"
        },
        {
          "id": "swell",
          "name": "Swellchain",
          "slug": "swell"
        },
        {
          "id": "sxnetwork",
          "name": "SX Network",
          "slug": "sxnetwork"
        },
        {
          "id": "taiko",
          "name": "Taiko Alethia",
          "slug": "taiko"
        },
        {
          "id": "unichain",
          "name": "Unichain",
          "slug": "unichain"
        },
        {
          "id": "worldchain",
          "name": "World Chain",
          "slug": "world"
        },
        {
          "id": "xlayer",
          "name": "X Layer",
          "slug": "xlayer"
        },
        {
          "id": "zeronetwork",
          "name": "ZERO Network",
          "slug": "zeronetwork"
        },
        {
          "id": "zircuit",
          "name": "Zircuit",
          "slug": "zircuit"
        },
        {
          "id": "zksync2",
          "name": "ZKsync Era",
          "slug": "zksync-era"
        },
        {
          "id": "zora",
          "name": "Zora",
          "slug": "zora"
        }
      ]
    }

• funki +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp-preu16",
      "dataAvailability": [
        {
          "name": "Data required to compute fraud proof is published offchain without onchain attestations",
          "description": "The project relies on DA challenges for data availability. If a DA challenger finds that the data behind a tx data commitment is not available,\n      they can submit a challenge which requires locking a bond within 12h. A challenge can be resolved by publishing the preimage data within an additional 12h.\n      In such a case, a portion of the challenger bond is burned, with the exact amount estimated as the cost incurred by the resolver to publish the full data,\n      meaning that the resolver and challenger will approximately lose the same amount of funds. The system is not secure if the malicious sequencer is able to outspend the altruistic challengers. If instead, after a challenge, the preimage data is not published, the chain reorgs to the last fully derivable state. This mechanism fully depends on the derivation rule of the L2 node and can only be verified in its source code, which [can be reviewed here](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7).",
          "references": [
            {
              "title": "OP Plasma specification",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md"
            },
            {
              "title": "Universal Plasma and DA Challenges - Ethresear.ch",
              "url": "https://ethresear.ch/t/universal-plasma-and-da-challenges/18629"
            },
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xfF00000000000000000000000000000084BB84Bb#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
            }
          ],
          "risks": [
            {
              "category": "Funds can be stolen if",
              "text": "the sequencer is malicious and is able to economically outspend the altruistic challengers."
            },
            {
              "category": "Funds can be stolen if",
              "text": "there is no challenger willing to challenge unavailable data commitments."
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• galxegravity +7 -1 Viewed

  • scalingTechnology +7 -1 Viewed

    {
      "architectureImage": "orbit-optimium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 1 out of 1.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            },
            {
              "category": "Users can be censored if",
              "text": "the committee restricts their access to the external data."
            }
          ],
          "references": [
            {
              "title": "Inside AnyTrust - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-anytrust"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 2y 9mo in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://etherscan.io/address/0x6F2E7F9B5Db5e4e9B5B1181D2Eb0e4972500C324#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 2y 9mo and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn't timely process a message. Only messages processed with a delay greater than 428424622y 1mo consume the buffer. The buffer is capped at 428424622y 1mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 428424622y 1mo.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 0.1 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 5d 14h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 5d 14h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 11d 4h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.1 ETH, level 2 requires a stake of 0.1 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• hashkey +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp-preu16",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x0004cb44C80b6Fbf8ceb1d80AF688C9f7C0b2aB5#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x18A7868ECe35A45aC9138108E5b6e021aD1038d1#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 3d 12h period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x18A7868ECe35A45aC9138108E5b6e021aD1038d1#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x18A7868ECe35A45aC9138108E5b6e021aD1038d1#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x18A7868ECe35A45aC9138108E5b6e021aD1038d1#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/hashkeychain.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/hashkeychain.json.zst).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• ink +2 -1 Viewed

  • scalingTechnology +2 -1 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp-permissionless",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x005969bf0EcbF6eDB6C47E5e94693b1C3651Be97#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/ink.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/ink.json.zst).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by anyone who has sufficient funds. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.08 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ]
            ],
            "risks": []
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 691.43 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "opfp"
    }

• lasernet +7 -1 Viewed

  • scalingTechnology +7 -1 Viewed

    {
      "architectureImage": "orbit-optimium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 1 out of 1.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            },
            {
              "category": "Users can be censored if",
              "text": "the committee restricts their access to the external data."
            }
          ],
          "references": [
            {
              "title": "Inside AnyTrust - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-anytrust"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://etherscan.io/address/0x6F2E7F9B5Db5e4e9B5B1181D2Eb0e4972500C324#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn't timely process a message. Only messages processed with a delay greater than 428424622y 1mo consume the buffer. The buffer is capped at 428424622y 1mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 428424622y 1mo.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 0.1 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 5d 14h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 5d 14h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 11d 4h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.1 ETH, level 2 requires a stake of 0.1 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• lisk +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp-preu16",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xFf00000000000000000000000000000000001135#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 32, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• lyra +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-optimium-superchain-opfp",
      "dataAvailability": [
        {
          "name": "Data is posted to Celestia",
          "description": "Transactions roots are posted onchain and the full data is posted on Celestia.  Since the Blobstream bridge is not used, availability of the data is not verified against Celestia validators, meaning that the Sequencer can single-handedly publish unavailable roots. If Celestia becomes unavailable, the sequencer falls back to Ethereum.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the sequencer posts an unavailable transaction root.",
              "isCritical": true
            },
            {
              "category": "Funds can be lost if",
              "text": "the data is not available on the external provider.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Introducing Blobstream: streaming modular DA to Ethereum",
              "url": "https://blog.celestia.org/introducing-blobstream/"
            },
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x5f7f7f6DB967F0ef10BdA0678964DBA185d16c50#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• metal +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xc83f7D9F2D4A76E81145849381ABA02602373723#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/metal.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/metal.json.zst).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• mint +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp-preu16",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x4e31448a098393727b786e25B54E59DcA1b77FE1#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x8953eCB2AAbB9260662241eC505250A1C63eF776#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x8953eCB2AAbB9260662241eC505250A1C63eF776#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x8953eCB2AAbB9260662241eC505250A1C63eF776#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x8953eCB2AAbB9260662241eC505250A1C63eF776#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://api.conduit.xyz/file/v1/optimism/rollup/mint-mainnet-0).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://api.conduit.xyz/file/v1/optimism/genesis/mint-mainnet-0).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• mode +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x24E59d9d3Bd73ccC28Dc54062AF7EF7bFF58Bd67#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/mode.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/mode.json.zst).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• muster +7 -1 Viewed

  • scalingTechnology +7 -1 Viewed

    {
      "architectureImage": "orbit-optimium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 1 out of 1.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            },
            {
              "category": "Users can be censored if",
              "text": "the committee restricts their access to the external data."
            }
          ],
          "references": [
            {
              "title": "Inside AnyTrust - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-anytrust"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://arbiscan.io/address/0xfEB2537afD8519d16d0CcEa741A70f97f3D4288B#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn't timely process a message. Only messages processed with a delay greater than 1634y 3mo consume the buffer. The buffer is capped at 1634y 3mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 1634y 3mo.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 0.1 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 30m. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 1d. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 2d. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 1.0 ETH, level 2 requires a stake of 1.0 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• nillion +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-optimium-superchain-opfp",
      "dataAvailability": [
        {
          "name": "Data is posted to Celestia",
          "description": "Transactions roots are posted onchain and the full data is posted on Celestia.  Since the Blobstream bridge is not used, availability of the data is not verified against Celestia validators, meaning that the Sequencer can single-handedly publish unavailable roots.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the sequencer posts an unavailable transaction root.",
              "isCritical": true
            },
            {
              "category": "Funds can be lost if",
              "text": "the data is not available on the external provider.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Introducing Blobstream: streaming modular DA to Ethereum",
              "url": "https://blog.celestia.org/introducing-blobstream/"
            },
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x00F57326D44451ea7Cd8aDBb2B27573C81BD060b#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "warning": "The fault proof system is deployed but is not functional. The chain ID is not included in the op-program superchain registry, causing the dispute game to panic during execution. Security relies entirely on the permissioned proposer and challengers."
    }

• nova +7 -1 Viewed

  • scalingTechnology +7 -1 Viewed

    {
      "architectureImage": "orbit-optimium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 5 out of 6.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            },
            {
              "category": "Users can be censored if",
              "text": "the committee restricts their access to the external data."
            }
          ],
          "references": [
            {
              "title": "Inside AnyTrust - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-anytrust"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://etherscan.io/address/0x98a58ADAb0f8A66A1BF4544d804bc0475dff32c7#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible and Stylus smart contracts are supported",
          "description": "Arbitrum One supports smart contracts written in Solidity and other programming languages (Rust, C++) that compile to WASM. Such smart contracts are executed by nodes using either a geth fork or [a fork of wasmer](https://github.com/OffchainLabs/wasmer) inside the Nitro node, and can be proven with the onchain WASM VM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            },
            {
              "title": "A gentle introduction: Stylus",
              "url": "https://docs.arbitrum.io/stylus/stylus-gentle-introduction"
            }
          ]
        },
        {
          "name": "Arbitrum DAO is in charge of upgrades",
          "description": "Arbitrum DAO allows $ARB token holders to propose and vote on changes to the organization and the technologies it governs. The governance smart contracts are implemented on Arbitrum One rollup chain. The DAO can upgrade the Arbitrum One contracts on L2 with 2d delay and - using L2 --> L1 Governance Relay, update contracts on L1 with additional 3d delay + 6d 8h delay for all L2 --> L1 messages (in total a delay of 11d 8h), with an additional 8d if a challenge has been present in the state root that relays the message. The Security Council can upgrade the contracts without any delay. It can also cancel any upgrades initiated by the DAO.",
          "risks": [],
          "references": [
            {
              "title": "Arbitrum DAO",
              "url": "https://docs.arbitrum.foundation/concepts/arbitrum-dao"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn't timely process a message. Only messages processed with a delay greater than 1h consume the buffer. The buffer is capped at 2d. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 1h.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 1.0 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 6d 8h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 6d 8h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 12d 17h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 1.0 ETH, level 2 requires a stake of 1.0 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "upgradesAndGovernance": {
        "content": "All critical system smart contracts are upgradeable (can be arbitrarily changed). This permission is governed by the Arbitrum Decentralized Autonomous Organization (DAO)\nand their elected Security Council. The Arbitrum DAO controls Arbitrum One and Arbitrum Nova through upgrades and modifications to their smart contracts on Layer 1 Ethereum and the Layer 2s.\nWhile the DAO governs through token-weighted governance in their associated ARB token, the Security Council can directly act through\nmultisigs on all three chains. Although they are technically separate and connect to different target permissions,\ntheir member- and threshold configuration is kept in sync by a manager contract on Arbitrum One sending crosschain transactions.\n\nRegular upgrades, Admin- and Owner actions originate from either the Arbitrum DAO or the non-emergency (Proposer-) Security Council on Arbitrum One\nand pass through multiple delays and timelocks before being executed at their destination. Contrarily, the three Emergency Security Council multisigs\n(one on each chain: Arbitrum One, Ethereum, Arbitrum Nova) can skip delays and directly access all admin- and upgrade functions of all smart contracts.\nThese two general paths have the same destination: the respective UpgradeExecutor smart contract.\n\nRegular upgrades are scheduled in the L2 Timelock. The proposer Security Council can do this directly and the Arbitrum DAO (ARB token holders and delegates) must meet a\nCoreGovernor-enforced 50% threshold of the votable tokens. The L2 Timelock queues the transaction for a 8d delay and then sends it to the Outbox contract on Ethereum. This incurs another delay (the challenge period) of 6d 8h, which is extended by an additional 2d if the top-level assertion has been challenged.\nWhen that has passed, the L1 Timelock delays for additional 3d. Both timelocks serve as delays during which the transparent transaction contents can be audited,\nand, in the case of the final L1 timelock, cancelled by the Emergency Security Council. Finally, the transaction can be executed, calling Admin- or Owner restricted functions of the respective destination smart contracts\nthrough the UpgradeExecutor on Ethereum. If the predefined  transaction destination is Arbitrum One or -Nova, this last call is executed on L2 through the canonical bridge and the aliased address of the L1 Timelock.\n\nOperator roles like the Sequencers and Validators are managed using the same paths.\nSequencer changes can be delegated to a Batch Poster Manager role.\n\nTransactions targeting the Arbitrum DAO Treasury can be scheduled in the 3d\nTreasury Timelock by meeting a TreasuryGovernor-enforced 40% threshold of votable ARB tokens. The Security Council cannot regularly cancel\nthese transactions or schedule different ones but can overwrite them anyway by having upgrade permissions for all the underlying smart contracts."
      },
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• onyx +7 -1 Viewed

  • scalingTechnology +7 -1 Viewed

    {
      "architectureImage": "orbit-optimium-fastconfirm",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 1 out of 1.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            },
            {
              "category": "Users can be censored if",
              "text": "the committee restricts their access to the external data."
            }
          ],
          "references": [
            {
              "title": "Inside AnyTrust - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-anytrust"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://basescan.org/address/0x51dEDBD2f190E0696AFbEE5E60bFdE96d86464ec#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn't timely process a message. Only messages processed with a delay greater than 428424622y 1mo consume the buffer. The buffer is capped at 428424622y 1mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 428424622y 1mo.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 0.1 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 1mo 3d. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 1mo 3d. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 2mo 7d. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.1 ETH, level 2 requires a stake of 0.1 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• optimism +2 -1 Viewed

  • scalingTechnology +2 -1 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp-permissionless",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xFF00000000000000000000000000000000000010#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/op.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "Since OP Mainnet has migrated from the OVM to Bedrock, a node must be synced using a data directory that can be found [here](https://docs.optimism.io/builders/node-operators/management/snapshots). To reproduce the migration itself, see this [guide](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by anyone who has sufficient funds. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.08 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ]
            ],
            "risks": []
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 691.43 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "opfp",
      "upgradesAndGovernance": {
        "content": "All contracts are upgradable by the `SuperchainProxyAdmin` which is controlled by a 2/2 multisig composed by the Optimism Foundation and a Security Council. The Guardian role is assigned to the Security Council multisig, with a Safe Module that limits the Optimism Foundation to act through it to stop withdrawals in the whole Superchain or specific individual chains. Each pause automatically expires after 3 months if not extended or unpaused by the Security Council. The Security Council can remove the module if the Foundation becomes malicious. The single Sequencer actor can be modified by the `OpFoundationOperationsSafe` via the `SystemConfig` contract. The SuperchainProxyAdminOwner can recover dispute bonds in case of bugs that would distribute them incorrectly. \n\nAt the moment, for regular upgrades, the DAO signals its intent by voting on upgrade proposals, but has no direct control over the upgrade process."
      }
    }

• orderly +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-optimium-superchain-opfp",
      "dataAvailability": [
        {
          "name": "Data is posted to Celestia",
          "description": "Transactions roots are posted onchain and the full data is posted on Celestia.  Since the Blobstream bridge is not used, availability of the data is not verified against Celestia validators, meaning that the Sequencer can single-handedly publish unavailable roots. If Celestia becomes unavailable, the sequencer falls back to Ethereum.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the sequencer posts an unavailable transaction root.",
              "isCritical": true
            },
            {
              "category": "Funds can be lost if",
              "text": "the data is not available on the external provider.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Introducing Blobstream: streaming modular DA to Ethereum",
              "url": "https://blog.celestia.org/introducing-blobstream/"
            },
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x08aA34cC843CeEBcC88A627F18430294aA9780be#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        }
      ],
      "detailedDescription": "While ETH deposited to Orderly is using an OP Stack canonical bridge, the multichain USDC escrows are sending / receiving their deposit / withdrawal messages through the external LayerZero v1 AMB.",
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• pepeunchained2 +7 -1 Viewed

  • scalingTechnology +7 -1 Viewed

    {
      "architectureImage": "orbit-optimium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 1 out of 1.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            },
            {
              "category": "Users can be censored if",
              "text": "the committee restricts their access to the external data."
            }
          ],
          "references": [
            {
              "title": "Inside AnyTrust - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-anytrust"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://etherscan.io/address/0x6F2E7F9B5Db5e4e9B5B1181D2Eb0e4972500C324#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn't timely process a message. Only messages processed with a delay greater than 428424622y 1mo consume the buffer. The buffer is capped at 428424622y 1mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 428424622y 1mo.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 0.1 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 5d 14h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 5d 14h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 11d 4h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.1 ETH, level 2 requires a stake of 0.1 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• phala +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x5A2a0698355D06cd5c4e3872D2Bc6B9f6a89d39B#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• plumenetwork +7 -1 Viewed

  • scalingTechnology +7 -1 Viewed

    {
      "architectureImage": "orbit-optimium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 1 out of 1.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            },
            {
              "category": "Users can be censored if",
              "text": "the committee restricts their access to the external data."
            }
          ],
          "references": [
            {
              "title": "Inside AnyTrust - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-anytrust"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://etherscan.io/address/0x6F2E7F9B5Db5e4e9B5B1181D2Eb0e4972500C324#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer mechanism is present in the code but is effectively disabled due to buffer parameters being set to extreme values.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 0.1 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 5d 14h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 5d 14h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 11d 4h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.1 ETH, level 2 requires a stake of 0.1 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• polynomial +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x0bd57e83B5E0f9eCD84d559bB58e1EcFEEdD2565#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://api.conduit.xyz/file/v1/optimism/rollup/polynomial-mainnet-0).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://api.conduit.xyz/file/v1/optimism/genesis/polynomial-mainnet-0).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• powerloom +7 -1 Viewed

  • scalingTechnology +7 -1 Viewed

    {
      "architectureImage": "orbit-optimium-fastconfirm",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 1 out of 1.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            },
            {
              "category": "Users can be censored if",
              "text": "the committee restricts their access to the external data."
            }
          ],
          "references": [
            {
              "title": "Inside AnyTrust - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-anytrust"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://etherscan.io/address/0x6F2E7F9B5Db5e4e9B5B1181D2Eb0e4972500C324#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn't timely process a message. Only messages processed with a delay greater than 428424622y 1mo consume the buffer. The buffer is capped at 428424622y 1mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 428424622y 1mo.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 0.1 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 5d 14h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 5d 14h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 11d 4h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.1 ETH, level 2 requires a stake of 0.1 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• [ADDED] robinhood +1533 -0 Viewed

  • id +1 -0 Viewed

    "robinhood"

  • slug +1 -0 Viewed

    "robinhood"

  • name +1 -0 Viewed

    "Robinhood Chain"

  • shortName +1 -0 Viewed

    null

  • aliases +1 -0 Viewed

    null

  • addedAt +1 -0 Viewed

    1782864000

  • statuses +15 -0 Viewed

    {
      "reviewStatus": "inReview",
      "unverifiedContracts": [
        "eth:0x23A19d23e89166adedbDcB432518AB01e4272D94",
        "eth:0x6f38FC91105Fc9a43931DcA33450ab3315E3D4Fa",
        "eth:0xBd0D173EEb87D57A09521c24388a12789F33ba96",
        "eth:0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3",
        "eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf",
        "eth:0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D",
        "eth:0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9",
        "eth:0xc34f4907822d1cDC6aE3038Be22e6f12DEa35bd4",
        "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD",
        "eth:0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3"
      ]
    }

  • display +51 -0 Viewed

    {
      "badges": [
        {
          "id": "EVM",
          "type": "VM",
          "name": "EVM",
          "description": "This project uses the Ethereum Virtual Machine to run its smart contracts and supports the Solidity programming language",
          "action": {
            "type": "scalingFilter",
            "id": "vm",
            "value": "EVM"
          }
        },
        {
          "id": "EthereumBlobs",
          "type": "DA",
          "name": "Ethereum with blobs",
          "description": "This project is posting its data to Ethereum as blobs",
          "action": {
            "type": "publicDaHighlight",
            "slug": "ethereum"
          }
        },
        {
          "id": "Orbit",
          "type": "Stack",
          "name": "Built on Arbitrum Orbit",
          "description": "The project is built on Arbitrum Orbit",
          "action": {
            "type": "scalingFilter",
            "id": "stack",
            "value": "Arbitrum"
          }
        }
      ],
      "description": "Robinhood Chain is an Arbitrum Orbit Layer 2 operated by Robinhood, focused on tokenized real-world assets (such as stocks and ETFs) and onchain financial services including 24/7 trading, lending, and borrowing.\n\nRobinhood Chain is part of Robinhood's broader mission to democratize access to global financial markets and to empower users and developers with modern blockchain tools.",
      "links": {
        "websites": [
          "https://robinhood.com/chain/"
        ],
        "documentation": [
          "https://docs.robinhood.com/chain"
        ],
        "explorers": [
          "https://robinhoodchain.blockscout.com"
        ],
        "socialMedia": [
          "https://x.com/RobinhoodApp"
        ]
      }
    }

  • colors +1 -0 Viewed

    null

  • ecosystemColors +10 -0 Viewed

    {
      "primary": {
        "light": "#12AAFF",
        "dark": "#33BFFF"
      },
      "secondary": {
        "light": "#12AAFF",
        "dark": "#0A6EA3"
      }
    }

  • milestones +16 -0 Viewed

    [
      {
        "title": "Mainnet launch",
        "url": "https://robinhood.com/chain/",
        "date": "2026-07-01T00:00:00Z",
        "description": "Robinhood Chain opens to the public, removing the transaction-access whitelist.",
        "type": "general"
      },
      {
        "title": "Public testnet launch",
        "url": "https://robinhood.com/us/en/newsroom/robinhood-chain-launches-public-testnet/",
        "date": "2026-02-10T00:00:00Z",
        "description": "Robinhood Chain opens its public testnet.",
        "type": "general"
      }
    ]

  • chainConfig +20 -0 Viewed

    {
      "apis": [
        {
          "type": "rpc",
          "url": "https://rpc.mainnet.chain.robinhood.com",
          "callsPerMinute": 600
        },
        {
          "type": "blockscout",
          "url": "https://robinhoodchain.blockscout.com/api"
        }
      ],
      "chainId": 4663,
      "explorerUrl": "https://robinhoodchain.blockscout.com",
      "gasTokens": [
        "ETH"
      ],
      "name": "robinhood",
      "sinceTimestamp": 1777567931
    }

  • escrows +111 -0 Viewed

    [
      {
        "address": "0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3",
        "sinceTimestamp": 1777567919,
        "tokens": [
          "ETH"
        ],
        "contract": {
          "isVerified": false,
          "address": "eth:0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3",
          "upgradeability": {
            "proxyType": "EIP1967 proxy",
            "admins": [
              "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
            ],
            "implementations": [
              "eth:0xC678f7B95A7D1F77c6024c0086301D21402854b1"
            ]
          },
          "chain": "ethereum",
          "pastUpgrades": [
            {
              "timestamp": 1777567919,
              "transactionHash": "0x7982d3d9da29185af78f7802cd2bdb04bdfb702766bb583c3b2804d762dc1fa8",
              "implementations": [
                "eth:0xC678f7B95A7D1F77c6024c0086301D21402854b1"
              ]
            }
          ],
          "description": "Contract managing Inboxes and Outboxes. It escrows ETH sent to L2.",
          "upgradableBy": [
            {
              "name": "ProxyAdmin",
              "delay": "no"
            }
          ],
          "url": "https://etherscan.io/address/0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3#code"
        },
        "chain": "ethereum",
        "includeInTotal": true,
        "chainId": 1
      },
      {
        "address": "0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0",
        "sinceTimestamp": 1777567931,
        "tokens": "*",
        "contract": {
          "name": "L1ERC20Gateway",
          "isVerified": true,
          "address": "eth:0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0",
          "upgradeability": {
            "proxyType": "EIP1967 proxy",
            "admins": [
              "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
            ],
            "implementations": [
              "eth:0xf43bce5D32742FFC862eA182b0b5544CbDBB0F02"
            ]
          },
          "chain": "ethereum",
          "pastUpgrades": [
            {
              "timestamp": 1777567931,
              "transactionHash": "0x80b3040805a5b37638da6908f951e15306edabbf4773c7b53116daef4f72a04f",
              "implementations": [
                "eth:0xf43bce5D32742FFC862eA182b0b5544CbDBB0F02"
              ]
            }
          ],
          "description": "Escrows deposited ERC-20 assets for the canonical Bridge. Upon depositing, a generic token representation will be minted at the destination. Withdrawals are initiated by the Outbox contract.",
          "url": "https://etherscan.io/address/0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0#code"
        },
        "chain": "ethereum",
        "includeInTotal": true,
        "chainId": 1
      },
      {
        "address": "0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B",
        "sinceTimestamp": 1777567931,
        "tokens": "*",
        "contract": {
          "name": "L1WethGateway",
          "isVerified": true,
          "address": "eth:0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B",
          "upgradeability": {
            "proxyType": "EIP1967 proxy",
            "admins": [
              "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
            ],
            "implementations": [
              "eth:0xa86996bED19547f7dEf22a087dD61b5F9Fb6C684"
            ]
          },
          "chain": "ethereum",
          "pastUpgrades": [
            {
              "timestamp": 1777567931,
              "transactionHash": "0x80b3040805a5b37638da6908f951e15306edabbf4773c7b53116daef4f72a04f",
              "implementations": [
                "eth:0xa86996bED19547f7dEf22a087dD61b5F9Fb6C684"
              ]
            }
          ],
          "description": "Escrows WETH deposited through the canonical Bridge, minting a wrapped representation at the destination.",
          "url": "https://etherscan.io/address/0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B#code"
        },
        "chain": "ethereum",
        "includeInTotal": true,
        "chainId": 1
      }
    ]

  • bridgeInfo +1 -0 Viewed

    null

  • bridgeRisks +1 -0 Viewed

    null

  • bridgeTechnology +1 -0 Viewed

    null

  • scalingInfo +36 -0 Viewed

    {
      "capability": "universal",
      "daLayer": [
        "Ethereum"
      ],
      "hostChain": {
        "id": "ethereum",
        "slug": "ethereum",
        "name": "Ethereum"
      },
      "layer": "layer2",
      "proofSystem": {
        "type": "Optimistic",
        "name": "BoLD",
        "challengeProtocol": "Interactive"
      },
      "purposes": [
        "Universal",
        "RWA"
      ],
      "reasonsForBeingOther": [
        {
          "label": "Closed proofs",
          "shortDescription": "There are less than 5 external actors that can submit challenges",
          "description": "Projects without a sufficiently decentralized set of challengers rely on few entities to safely update the state. A small set of challengers can collude with the proposer to finalize an invalid state, which can cause loss of funds."
        }
      ],
      "stacks": [
        "Arbitrum"
      ],
      "stage": "Stage 0",
      "type": "Other",
      "vm": [
        "EVM"
      ]
    }

  • scalingStage +84 -0 Viewed

    {
      "message": {
        "type": "underReview",
        "text": "The requirement for available node software is under review"
      },
      "missing": {
        "nextStage": "Stage 1",
        "requirements": [
          "Upgrades executed by actors with more centralized control than a Security Council provide less than 7d for users to exit if the permissioned operator is down or censoring.",
          "The Security Council is not properly set up."
        ],
        "principle": "Compromising ≥75% of the Security Council should be the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window."
      },
      "stage": "Stage 0",
      "summary": [
        {
          "stage": "Stage 0",
          "requirements": [
            {
              "satisfied": true,
              "description": "A complete and functional proof system is deployed."
            },
            {
              "satisfied": false,
              "description": "Fraud proof submission is not sufficiently decentralized."
            },
            {
              "satisfied": true,
              "description": "The project calls itself a rollup."
            },
            {
              "satisfied": true,
              "description": "State roots are posted to Ethereum L1."
            },
            {
              "satisfied": true,
              "description": "Inputs for the state transition function are posted to Ethereum L1."
            },
            {
              "satisfied": "UnderReview",
              "description": "A source-available node exists that can recreate the state from Ethereum L1 data. Please note that the L2BEAT team has not verified the validity of the node source code."
            }
          ]
        },
        {
          "stage": "Stage 1",
          "requirements": [
            {
              "satisfied": true,
              "description": "Users are able to exit without the help of the permissioned operators."
            },
            {
              "satisfied": false,
              "description": "Upgrades executed by actors with more centralized control than a Security Council provide less than 7d for users to exit if the permissioned operator is down or censoring."
            },
            {
              "satisfied": false,
              "description": "The Security Council is not properly set up."
            }
          ],
          "principle": {
            "satisfied": false,
            "description": "Compromising ≥75% of the Security Council should be the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window."
          }
        },
        {
          "stage": "Stage 2",
          "requirements": [
            {
              "satisfied": false,
              "description": "Fraud proof submission is open only to whitelisted actors."
            },
            {
              "satisfied": false,
              "description": "Upgrades unrelated to onchain provable bugs provide less than 30d to exit."
            },
            {
              "satisfied": false,
              "description": "The Security Council's actions are not confined to onchain provable bugs."
            }
          ]
        }
      ]
    }

  • scalingRisks +45 -0 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "Fraud proofs (INT)",
          "description": "Fraud proofs only allow 2 WHITELISTED actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve. The challenge protocol can be subject to delay attacks. There is a 6d 8h challenge period.",
          "executionDelay": 172800,
          "executionDelayMode": "if-challenged",
          "challengeDelay": 549816,
          "permissioned": true,
          "defenderAdvantage": "not-applicable",
          "sentiment": "bad",
          "orderHint": 2,
          "initialBond": {
            "value": "1.0"
          },
          "secondLine": "6d 8h challenge period\n+ 2d execution delay"
        },
        "dataAvailability": {
          "value": "Onchain",
          "description": "All of the data needed for proof construction is published on Ethereum L1.",
          "sentiment": "good",
          "orderHint": null
        },
        "exitWindow": {
          "value": "None",
          "description": "There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.",
          "sentiment": "bad",
          "orderHint": -345600
        },
        "sequencerFailure": {
          "value": "Self sequence",
          "description": "In the event of a sequencer failure, users can force transactions to be included in the project's chain by sending them to L1. There can be up to a 4d delay on this operation.",
          "sentiment": "good",
          "orderHint": 345600,
          "secondLine": "4d delay"
        },
        "proposerFailure": {
          "value": "Self propose",
          "description": "Anyone can become a Proposer after 28d of inactivity from the currently whitelisted Proposers.",
          "sentiment": "good",
          "orderHint": 2419200,
          "secondLine": "28d delay"
        }
      }
    }

  • scalingDa +21 -0 Viewed

    [
      {
        "layer": {
          "value": "Ethereum",
          "secondLine": "Blobs or Calldata",
          "sentiment": "good",
          "description": "The data is posted to Ethereum as calldata or blobs.",
          "projectId": "ethereum"
        },
        "bridge": {
          "value": "Enshrined",
          "sentiment": "good",
          "description": "The validating bridge has access to all the data, as it is posted onchain.",
          "projectId": "ethereum"
        },
        "mode": {
          "value": "Transaction data",
          "secondLine": "Compressed"
        }
      }
    ]

  • scalingTechnology +142 -0 Viewed

    {
      "architectureImage": "orbit-rollup",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Sequencing followed by deterministic execution - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/#sequencing-followed-by-deterministic-execution"
            },
            {
              "title": "SequencerInbox.sol - source code, addSequencerL2BatchFromOrigin function",
              "url": "https://etherscan.io/address/0xb015D78fb9B890e96FD3E23819b2C8D9fffA3cC5#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 4d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://etherscan.io/address/0xb015D78fb9B890e96FD3E23819b2C8D9fffA3cC5#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 4d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn't timely process a message. Only messages processed with a delay greater than 1634y 3mo consume the buffer. The buffer is capped at 1634y 3mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 1634y 3mo.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 1.0 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 6d 8h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 6d 8h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 12d 17h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.000000000000000001 ETH, level 2 requires a stake of 0.000000000000000001 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

  • daLayer +1 -0 Viewed

    null

  • daBridge +1 -0 Viewed

    null

  • customDa +1 -0 Viewed

    null

  • zkCatalogInfo +1 -0 Viewed

    null

  • interopConfig +1 -0 Viewed

    null

  • privacyInfo +1 -0 Viewed

    null

  • tvsInfo +4 -0 Viewed

    {
      "associatedTokens": [],
      "warnings": []
    }

  • tvsConfig +79 -0 Viewed

    [
      {
        "mode": "auto",
        "id": "robinhood-ETH",
        "priceId": "ethereum",
        "symbol": "ETH",
        "name": "Ether",
        "iconUrl": "https://assets.coingecko.com/coins/images/279/large/ethereum.png?1595348880",
        "amount": {
          "type": "calculation",
          "operator": "sum",
          "arguments": [
            {
              "type": "balanceOfEscrow",
              "chain": "ethereum",
              "sinceTimestamp": 1777567919,
              "address": "native",
              "decimals": 18,
              "escrowAddress": "0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3"
            },
            {
              "type": "balanceOfEscrow",
              "chain": "ethereum",
              "sinceTimestamp": 1777567931,
              "address": "native",
              "decimals": 18,
              "escrowAddress": "0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0"
            },
            {
              "type": "balanceOfEscrow",
              "chain": "ethereum",
              "sinceTimestamp": 1777567931,
              "address": "native",
              "decimals": 18,
              "escrowAddress": "0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B"
            }
          ]
        },
        "category": "ether",
        "source": "canonical",
        "isAssociated": false
      },
      {
        "mode": "auto",
        "id": "robinhood-USDG",
        "priceId": "global-dollar",
        "symbol": "USDG",
        "name": "Global Dollar",
        "iconUrl": "https://coin-images.coingecko.com/coins/images/51281/large/GDN_USDG_Token_200x200.png?1730484111",
        "amount": {
          "type": "totalSupply",
          "chain": "robinhood",
          "sinceTimestamp": 1778003991,
          "address": "0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168",
          "decimals": 6
        },
        "category": "stablecoin",
        "source": "native",
        "isAssociated": false
      },
      {
        "mode": "auto",
        "id": "robinhood-USDe",
        "priceId": "ethena-usde",
        "symbol": "USDe",
        "name": "USDe",
        "iconUrl": "https://coin-images.coingecko.com/coins/images/33613/large/usde.png?1733810059",
        "amount": {
          "type": "totalSupply",
          "chain": "robinhood",
          "sinceTimestamp": 1780403342,
          "address": "0x5d3a1Ff2b6BAb83b63cd9AD0787074081a52ef34",
          "decimals": 18
        },
        "category": "stablecoin",
        "source": "external",
        "isAssociated": false
      }
    ]

  • activityConfig +7 -0 Viewed

    {
      "adjustCount": {
        "type": "SubtractOne"
      },
      "startBlock": 1,
      "type": "block"
    }

  • livenessInfo +6 -0 Viewed

    {
      "explanation": "Robinhood Chain posts transaction data to the L1. For a transaction to be considered final, it has to be posted to the L1. Forced txs can be delayed up to 4d. The state root is settled 6d 8h after it has been posted.",
      "warnings": {
        "stateUpdates": "Please note, for Optimistic rollups the state is not finalized until the challenge period passes."
      }
    }

  • livenessConfig +1 -0 Viewed

    null

  • costsInfo +1 -0 Viewed

    {}

  • trackedTxsConfig +146 -0 Viewed

    [
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "liveness",
        "subtype": "batchSubmissions",
        "params": {
          "formula": "functionCall",
          "address": "0xBd0D173EEb87D57A09521c24388a12789F33ba96",
          "selector": "0xe0bc9729",
          "signature": "function addSequencerL2Batch(uint256 sequenceNumber,bytes calldata data,uint256 afterDelayedMessagesRead,address gasRefunder,uint256 prevMessageCount,uint256 newMessageCount)"
        }
      },
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "l2costs",
        "subtype": "batchSubmissions",
        "params": {
          "formula": "functionCall",
          "address": "0xBd0D173EEb87D57A09521c24388a12789F33ba96",
          "selector": "0xe0bc9729",
          "signature": "function addSequencerL2Batch(uint256 sequenceNumber,bytes calldata data,uint256 afterDelayedMessagesRead,address gasRefunder,uint256 prevMessageCount,uint256 newMessageCount)"
        }
      },
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "liveness",
        "subtype": "batchSubmissions",
        "params": {
          "formula": "functionCall",
          "address": "0xBd0D173EEb87D57A09521c24388a12789F33ba96",
          "selector": "0x8f111f3c",
          "signature": "function addSequencerL2BatchFromOrigin(uint256 sequenceNumber,bytes data,uint256 afterDelayedMessagesRead,address gasRefunder,uint256 prevMessageCount,uint256 newMessageCount)"
        }
      },
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "l2costs",
        "subtype": "batchSubmissions",
        "params": {
          "formula": "functionCall",
          "address": "0xBd0D173EEb87D57A09521c24388a12789F33ba96",
          "selector": "0x8f111f3c",
          "signature": "function addSequencerL2BatchFromOrigin(uint256 sequenceNumber,bytes data,uint256 afterDelayedMessagesRead,address gasRefunder,uint256 prevMessageCount,uint256 newMessageCount)"
        }
      },
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "liveness",
        "subtype": "batchSubmissions",
        "params": {
          "formula": "functionCall",
          "address": "0xBd0D173EEb87D57A09521c24388a12789F33ba96",
          "selector": "0x69cacded",
          "signature": "function addSequencerL2BatchFromOriginDelayProof(uint256 sequenceNumber, bytes data, uint256 afterDelayedMessagesRead, address gasRefunder, uint256 prevMessageCount, uint256 newMessageCount, tuple(bytes32 beforeDelayedAcc, tuple(uint8 kind, address sender, uint64 blockNumber, uint64 timestamp, uint256 inboxSeqNum, uint256 baseFeeL1, bytes32 messageDataHash) delayedMessage) delayProof)"
        }
      },
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "l2costs",
        "subtype": "batchSubmissions",
        "params": {
          "formula": "functionCall",
          "address": "0xBd0D173EEb87D57A09521c24388a12789F33ba96",
          "selector": "0x69cacded",
          "signature": "function addSequencerL2BatchFromOriginDelayProof(uint256 sequenceNumber, bytes data, uint256 afterDelayedMessagesRead, address gasRefunder, uint256 prevMessageCount, uint256 newMessageCount, tuple(bytes32 beforeDelayedAcc, tuple(uint8 kind, address sender, uint64 blockNumber, uint64 timestamp, uint256 inboxSeqNum, uint256 baseFeeL1, bytes32 messageDataHash) delayedMessage) delayProof)"
        }
      },
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "liveness",
        "subtype": "stateUpdates",
        "params": {
          "formula": "functionCall",
          "address": "0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9",
          "selector": "0xa04cee60",
          "signature": "function updateSendRoot(bytes32 root, bytes32 l2BlockHash) external"
        }
      },
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "l2costs",
        "subtype": "stateUpdates",
        "params": {
          "formula": "functionCall",
          "address": "0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9",
          "selector": "0xa04cee60",
          "signature": "function updateSendRoot(bytes32 root, bytes32 l2BlockHash) external"
        }
      },
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "liveness",
        "subtype": "batchSubmissions",
        "params": {
          "formula": "functionCall",
          "address": "0xBd0D173EEb87D57A09521c24388a12789F33ba96",
          "selector": "0x3e5aa082",
          "signature": "function addSequencerL2BatchFromBlobs(uint256 sequenceNumber,uint256 afterDelayedMessagesRead,address gasRefunder,uint256 prevMessageCount,uint256 newMessageCount)"
        }
      },
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "l2costs",
        "subtype": "batchSubmissions",
        "params": {
          "formula": "functionCall",
          "address": "0xBd0D173EEb87D57A09521c24388a12789F33ba96",
          "selector": "0x3e5aa082",
          "signature": "function addSequencerL2BatchFromBlobs(uint256 sequenceNumber,uint256 afterDelayedMessagesRead,address gasRefunder,uint256 prevMessageCount,uint256 newMessageCount)"
        }
      },
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "liveness",
        "subtype": "batchSubmissions",
        "params": {
          "formula": "functionCall",
          "address": "0xBd0D173EEb87D57A09521c24388a12789F33ba96",
          "selector": "0x917cf8ac",
          "signature": "function addSequencerL2BatchFromBlobsDelayProof(uint256 sequenceNumber, uint256 afterDelayedMessagesRead, address gasRefunder, uint256 prevMessageCount, uint256 newMessageCount, tuple(bytes32 beforeDelayedAcc, tuple(uint8 kind, address sender, uint64 blockNumber, uint64 timestamp, uint256 inboxSeqNum, uint256 baseFeeL1, bytes32 messageDataHash) delayedMessage) delayProof)"
        }
      },
      {
        "projectId": "robinhood",
        "sinceTimestamp": 1777567919,
        "type": "l2costs",
        "subtype": "batchSubmissions",
        "params": {
          "formula": "functionCall",
          "address": "0xBd0D173EEb87D57A09521c24388a12789F33ba96",
          "selector": "0x917cf8ac",
          "signature": "function addSequencerL2BatchFromBlobsDelayProof(uint256 sequenceNumber, uint256 afterDelayedMessagesRead, address gasRefunder, uint256 prevMessageCount, uint256 newMessageCount, tuple(bytes32 beforeDelayedAcc, tuple(uint8 kind, address sender, uint64 blockNumber, uint64 timestamp, uint256 inboxSeqNum, uint256 baseFeeL1, bytes32 messageDataHash) delayedMessage) delayProof)"
        }
      }
    ]

  • daTrackingConfig +11 -0 Viewed

    [
      {
        "type": "ethereum",
        "daLayer": "ethereum",
        "sinceBlock": 24994238,
        "inbox": "0xBd0D173EEb87D57A09521c24388a12789F33ba96",
        "sequencers": [
          "0xDaa526086787d9DEbE1D7F3FFdb1fE50cf8687F4"
        ]
      }
    ]

  • ecosystemInfo +3 -0 Viewed

    {
      "id": "arbitrum-orbit"
    }

  • ecosystemConfig +1 -0 Viewed

    null

  • permissions +105 -0 Viewed

    {
      "ethereum": {
        "roles": [],
        "actors": [
          {
            "id": "ProxyAdmin",
            "name": "ProxyAdmin",
            "accounts": [
              {
                "address": "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD",
                "type": "Contract",
                "isVerified": false,
                "name": "0x1232…90FD",
                "url": "https://etherscan.io/address/0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              }
            ],
            "chain": "ethereum",
            "description": "* Can upgrade **with no delay**\n  * Inbox \n  * UpgradeExecutor \n  * L1GatewayRouter \n  * EdgeChallengeManager \n  * L1ERC20Gateway \n  * SequencerInbox \n  * RollupEventInbox \n  * Bridge \n  * Outbox \n  * L1WethGateway ",
            "discoveryDrivenData": true
          },
          {
            "id": "Safe",
            "name": "Safe",
            "description": "A Multisig with 2/3 threshold. \n* Can upgrade **with no delay**\n  * RollupProxy [via: UpgradeExecutor]\n* Can interact with RollupProxy\n  * Pause and unpause and set important roles and parameters in the system contracts: Can delegate Sequencer management to a BatchPosterManager address, manage data availability and DACs, set the Sequencer-only window, introduce an allowList to the bridge and whitelist Inboxes/Outboxes [via: UpgradeExecutor]",
            "accounts": [
              {
                "address": "eth:0x1F3Bdec08A161Ca9e5480feF33A3B2278c2931C5",
                "type": "Contract",
                "isVerified": true,
                "name": "0x1F3B…31C5",
                "url": "https://etherscan.io/address/0x1F3Bdec08A161Ca9e5480feF33A3B2278c2931C5"
              }
            ],
            "chain": "ethereum",
            "references": [],
            "participants": [
              {
                "address": "eth:0x29631c2da9Ab1C0Ca1935A463842a9484E34Fa17",
                "type": "EOA",
                "isVerified": true,
                "name": "0x2963…Fa17",
                "url": "https://etherscan.io/address/0x29631c2da9Ab1C0Ca1935A463842a9484E34Fa17"
              },
              {
                "address": "eth:0x2584fd737d35bE395aa979b18602d0dE65f38b2c",
                "type": "EOA",
                "isVerified": true,
                "name": "0x2584…8b2c",
                "url": "https://etherscan.io/address/0x2584fd737d35bE395aa979b18602d0dE65f38b2c"
              },
              {
                "address": "eth:0xb89C85BE593e6A8f7e35AC481b5F75Fc4036f31c",
                "type": "EOA",
                "isVerified": true,
                "name": "0xb89C…f31c",
                "url": "https://etherscan.io/address/0xb89C85BE593e6A8f7e35AC481b5F75Fc4036f31c"
              }
            ],
            "discoveryDrivenData": true
          },
          {
            "id": "EOA-1-and-EOA-2",
            "name": "EOA 1 and EOA 2",
            "accounts": [
              {
                "address": "eth:0x992D8d50548fCcCaF11147A9a692c496011C8Aa0",
                "type": "EOA",
                "isVerified": true,
                "name": "0x992D…8Aa0",
                "url": "https://etherscan.io/address/0x992D8d50548fCcCaF11147A9a692c496011C8Aa0",
                "displayName": "EOA 1"
              },
              {
                "address": "eth:0xa0A1D8cd6f867a583a39232a477ff231aFD8eC4C",
                "type": "EOA",
                "isVerified": true,
                "name": "0xa0A1…eC4C",
                "url": "https://etherscan.io/address/0xa0A1D8cd6f867a583a39232a477ff231aFD8eC4C",
                "displayName": "EOA 2"
              }
            ],
            "chain": "ethereum",
            "description": "* Can interact with RollupProxy\n  * Can propose new state roots (called nodes) and challenge state roots on the host chain ",
            "discoveryDrivenData": true
          },
          {
            "id": "EOA-3",
            "name": "EOA 3",
            "accounts": [
              {
                "address": "eth:0xDaa526086787d9DEbE1D7F3FFdb1fE50cf8687F4",
                "type": "EOA",
                "isVerified": true,
                "name": "0xDaa5…87F4",
                "url": "https://etherscan.io/address/0xDaa526086787d9DEbE1D7F3FFdb1fE50cf8687F4",
                "displayName": "EOA 3"
              }
            ],
            "chain": "ethereum",
            "description": "* Can interact with SequencerInbox\n  * Can submit transaction batches or commitments to the SequencerInbox contract on the host chain ",
            "discoveryDrivenData": true
          }
        ]
      }
    }

  • contracts +593 -0 Viewed

    {
      "addresses": {
        "ethereum": [
          {
            "name": "RollupProxy",
            "isVerified": false,
            "address": "eth:0x23A19d23e89166adedbDcB432518AB01e4272D94",
            "upgradeability": {
              "proxyType": "Arbitrum proxy",
              "admins": [
                "eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"
              ],
              "implementations": [
                "eth:0xAb7A44CE7e66963d2116dCe74AB63eeF88266C82",
                "eth:0xedC23dFC7D1e57EC07eA5ff7419634DbAe08Ed2C"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567919,
                "transactionHash": "0x7982d3d9da29185af78f7802cd2bdb04bdfb702766bb583c3b2804d762dc1fa8",
                "implementations": [
                  "eth:0xAb7A44CE7e66963d2116dCe74AB63eeF88266C82",
                  "eth:0xedC23dFC7D1e57EC07eA5ff7419634DbAe08Ed2C"
                ]
              }
            ],
            "description": "Central contract for the project's configuration like its execution logic hash (`wasmModuleRoot`) and addresses of the other system contracts. Entry point for Proposers creating new assertions (state commitments) and Challengers submitting fraud proofs (In the Orbit stack, these two roles are both called Validators).\n* Roles:\n  * **admin**: UpgradeExecutor; ultimately Safe\n  * **getValidators**: EOA 1, EOA 2\n  * **owner**: UpgradeExecutor; ultimately Safe",
            "upgradableBy": [
              {
                "name": "Safe",
                "delay": "no"
              }
            ],
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0x23A19d23e89166adedbDcB432518AB01e4272D94#code"
          },
          {
            "name": "EdgeChallengeManager",
            "isVerified": false,
            "address": "eth:0x6f38FC91105Fc9a43931DcA33450ab3315E3D4Fa",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0xCAaa9332F940362aEAAADD1B0A59c229C4fD8f79"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567919,
                "transactionHash": "0x7982d3d9da29185af78f7802cd2bdb04bdfb702766bb583c3b2804d762dc1fa8",
                "implementations": [
                  "eth:0xCAaa9332F940362aEAAADD1B0A59c229C4fD8f79"
                ]
              }
            ],
            "description": "Contract that implements the main challenge protocol logic of the fraud proof system.\n* Roles:\n  * **admin**: ProxyAdmin",
            "upgradableBy": [
              {
                "name": "ProxyAdmin",
                "delay": "no"
              }
            ],
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0x6f38FC91105Fc9a43931DcA33450ab3315E3D4Fa#code"
          },
          {
            "name": "SequencerInbox",
            "isVerified": false,
            "address": "eth:0xBd0D173EEb87D57A09521c24388a12789F33ba96",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0xb015D78fb9B890e96FD3E23819b2C8D9fffA3cC5"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567919,
                "transactionHash": "0x7982d3d9da29185af78f7802cd2bdb04bdfb702766bb583c3b2804d762dc1fa8",
                "implementations": [
                  "eth:0xb015D78fb9B890e96FD3E23819b2C8D9fffA3cC5"
                ]
              }
            ],
            "description": "A sequencer (registered in this contract) can submit transaction batches or commitments here.\n* Roles:\n  * **admin**: ProxyAdmin\n  * **batchPosters**: EOA 3",
            "upgradableBy": [
              {
                "name": "ProxyAdmin",
                "delay": "no"
              }
            ],
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0xBd0D173EEb87D57A09521c24388a12789F33ba96#code"
          },
          {
            "name": "Bridge",
            "isVerified": false,
            "address": "eth:0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0xC678f7B95A7D1F77c6024c0086301D21402854b1"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567919,
                "transactionHash": "0x7982d3d9da29185af78f7802cd2bdb04bdfb702766bb583c3b2804d762dc1fa8",
                "implementations": [
                  "eth:0xC678f7B95A7D1F77c6024c0086301D21402854b1"
                ]
              }
            ],
            "description": "Escrow contract for the project's gas token (can be different from ETH). Keeps a list of allowed Inboxes and Outboxes for canonical bridge messaging.\n* Roles:\n  * **admin**: ProxyAdmin",
            "upgradableBy": [
              {
                "name": "ProxyAdmin",
                "delay": "no"
              }
            ],
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3#code"
          },
          {
            "name": "UpgradeExecutor",
            "isVerified": false,
            "address": "eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0x9149DF379237a935cf0658fE54D2325109493CBb"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567919,
                "transactionHash": "0x7982d3d9da29185af78f7802cd2bdb04bdfb702766bb583c3b2804d762dc1fa8",
                "implementations": [
                  "eth:0x9149DF379237a935cf0658fE54D2325109493CBb"
                ]
              }
            ],
            "description": "Central contract defining the access control permissions for upgrading the system contract implementations.\n* Roles:\n  * **admin**: ProxyAdmin\n  * **executors**: Safe",
            "upgradableBy": [
              {
                "name": "ProxyAdmin",
                "delay": "no"
              }
            ],
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0x552603b4bc1f5E896AF2854548D6380f45f1B4bf#code"
          },
          {
            "name": "Inbox",
            "isVerified": false,
            "address": "eth:0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0x8D3b93dfFFf4842E7B61FB553b383db2C6BC91c6"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567919,
                "transactionHash": "0x7982d3d9da29185af78f7802cd2bdb04bdfb702766bb583c3b2804d762dc1fa8",
                "implementations": [
                  "eth:0x8D3b93dfFFf4842E7B61FB553b383db2C6BC91c6"
                ]
              }
            ],
            "description": "Facilitates sending L1 to L2 messages like depositing ETH, but does not escrow funds.\n* Roles:\n  * **admin**: ProxyAdmin",
            "upgradableBy": [
              {
                "name": "ProxyAdmin",
                "delay": "no"
              }
            ],
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D#code"
          },
          {
            "name": "L1ERC20Gateway",
            "isVerified": true,
            "address": "eth:0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0xf43bce5D32742FFC862eA182b0b5544CbDBB0F02"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567931,
                "transactionHash": "0x80b3040805a5b37638da6908f951e15306edabbf4773c7b53116daef4f72a04f",
                "implementations": [
                  "eth:0xf43bce5D32742FFC862eA182b0b5544CbDBB0F02"
                ]
              }
            ],
            "description": "Escrows deposited ERC-20 assets for the canonical Bridge. Upon depositing, a generic token representation will be minted at the destination. Withdrawals are initiated by the Outbox contract.\n* Roles:\n  * **admin**: ProxyAdmin",
            "upgradableBy": [
              {
                "name": "ProxyAdmin",
                "delay": "no"
              }
            ],
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0#code"
          },
          {
            "name": "Outbox",
            "isVerified": false,
            "address": "eth:0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0x396765AEbE540575ef927F769b0d7b89594f931c"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567919,
                "transactionHash": "0x7982d3d9da29185af78f7802cd2bdb04bdfb702766bb583c3b2804d762dc1fa8",
                "implementations": [
                  "eth:0x396765AEbE540575ef927F769b0d7b89594f931c"
                ]
              }
            ],
            "description": "Facilitates L2 to L1 contract calls: Messages initiated from L2 (for example withdrawal messages) eventually resolve in execution on L1.\n* Roles:\n  * **admin**: ProxyAdmin",
            "upgradableBy": [
              {
                "name": "ProxyAdmin",
                "delay": "no"
              }
            ],
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9#code"
          },
          {
            "name": "L1GatewayRouter",
            "isVerified": true,
            "address": "eth:0x6a2E3a1e16FC29f27Ce61429746D558d656975bB",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0x6525137BfF366fbc0A89E3e5A4d244B5A0090a6D"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567931,
                "transactionHash": "0x80b3040805a5b37638da6908f951e15306edabbf4773c7b53116daef4f72a04f",
                "implementations": [
                  "eth:0x6525137BfF366fbc0A89E3e5A4d244B5A0090a6D"
                ]
              }
            ],
            "description": "This routing contract maps tokens to the correct escrow (gateway) to be then bridged with canonical messaging.\n* Roles:\n  * **admin**: ProxyAdmin",
            "upgradableBy": [
              {
                "name": "ProxyAdmin",
                "delay": "no"
              }
            ],
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0x6a2E3a1e16FC29f27Ce61429746D558d656975bB#code"
          },
          {
            "name": "OneStepProverMath",
            "isVerified": true,
            "address": "eth:0x4B15E064d5d55705E89080bDEA4BFe4cF20D6114",
            "upgradeability": {
              "proxyType": "immutable",
              "admins": [],
              "implementations": [],
              "immutable": true
            },
            "chain": "ethereum",
            "description": "One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.\n",
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0x4B15E064d5d55705E89080bDEA4BFe4cF20D6114#code"
          },
          {
            "name": "OneStepProofEntry",
            "isVerified": true,
            "address": "eth:0x5087a6fD526eFD5c6770d94D0c325de0e2A2c44D",
            "upgradeability": {
              "proxyType": "immutable",
              "admins": [],
              "implementations": [],
              "immutable": true
            },
            "chain": "ethereum",
            "description": "One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.\n",
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0x5087a6fD526eFD5c6770d94D0c325de0e2A2c44D#code"
          },
          {
            "name": "OneStepProverMemory",
            "isVerified": true,
            "address": "eth:0x665CEA1cA6C36aB701f4C6AE895b156f79C51c35",
            "upgradeability": {
              "proxyType": "immutable",
              "admins": [],
              "implementations": [],
              "immutable": true
            },
            "chain": "ethereum",
            "description": "One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.\n",
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0x665CEA1cA6C36aB701f4C6AE895b156f79C51c35#code"
          },
          {
            "name": "OneStepProver0",
            "isVerified": true,
            "address": "eth:0x6fE84aC811EBEcd888Eca93757fEa378Bb03b00c",
            "upgradeability": {
              "proxyType": "immutable",
              "admins": [],
              "implementations": [],
              "immutable": true
            },
            "chain": "ethereum",
            "description": "One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.\n",
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0x6fE84aC811EBEcd888Eca93757fEa378Bb03b00c#code"
          },
          {
            "name": "Wrapped Ether Token",
            "isVerified": true,
            "address": "eth:0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
            "upgradeability": {
              "proxyType": "immutable",
              "admins": [],
              "implementations": [],
              "immutable": true
            },
            "chain": "ethereum",
            "description": "",
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2#code"
          },
          {
            "name": "RollupEventInbox",
            "isVerified": false,
            "address": "eth:0xc34f4907822d1cDC6aE3038Be22e6f12DEa35bd4",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0x796FeE4adceD1cb47a3e3d1B6925472F8fC8f1f9"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567919,
                "transactionHash": "0x7982d3d9da29185af78f7802cd2bdb04bdfb702766bb583c3b2804d762dc1fa8",
                "implementations": [
                  "eth:0x796FeE4adceD1cb47a3e3d1B6925472F8fC8f1f9"
                ]
              }
            ],
            "description": "Helper contract sending configuration data over the bridge during the systems initialization.\n* Roles:\n  * **admin**: ProxyAdmin",
            "upgradableBy": [
              {
                "name": "ProxyAdmin",
                "delay": "no"
              }
            ],
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0xc34f4907822d1cDC6aE3038Be22e6f12DEa35bd4#code"
          },
          {
            "name": "OneStepProverHostIo",
            "isVerified": true,
            "address": "eth:0xe1aAfAfBde42f043495B39d1a15a58E91c894Fbf",
            "upgradeability": {
              "proxyType": "immutable",
              "admins": [],
              "implementations": [],
              "immutable": true
            },
            "chain": "ethereum",
            "description": "One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.\n",
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0xe1aAfAfBde42f043495B39d1a15a58E91c894Fbf#code"
          },
          {
            "name": "L1WethGateway",
            "isVerified": true,
            "address": "eth:0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0xa86996bED19547f7dEf22a087dD61b5F9Fb6C684"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567931,
                "transactionHash": "0x80b3040805a5b37638da6908f951e15306edabbf4773c7b53116daef4f72a04f",
                "implementations": [
                  "eth:0xa86996bED19547f7dEf22a087dD61b5F9Fb6C684"
                ]
              }
            ],
            "description": "* Roles:\n  * **admin**: ProxyAdmin",
            "upgradableBy": [
              {
                "name": "ProxyAdmin",
                "delay": "no"
              }
            ],
            "discoveryDrivenData": true,
            "url": "https://etherscan.io/address/0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B#code"
          }
        ]
      },
      "escrows": [
        {
          "address": "0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3",
          "sinceTimestamp": 1777567919,
          "tokens": [
            "ETH"
          ],
          "contract": {
            "isVerified": false,
            "address": "eth:0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0xC678f7B95A7D1F77c6024c0086301D21402854b1"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567919,
                "transactionHash": "0x7982d3d9da29185af78f7802cd2bdb04bdfb702766bb583c3b2804d762dc1fa8",
                "implementations": [
                  "eth:0xC678f7B95A7D1F77c6024c0086301D21402854b1"
                ]
              }
            ],
            "description": "Contract managing Inboxes and Outboxes. It escrows ETH sent to L2.",
            "upgradableBy": [
              {
                "name": "ProxyAdmin",
                "delay": "no"
              }
            ],
            "url": "https://etherscan.io/address/0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3#code"
          },
          "chain": "ethereum",
          "includeInTotal": true,
          "chainId": 1
        },
        {
          "address": "0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0",
          "sinceTimestamp": 1777567931,
          "tokens": "*",
          "contract": {
            "name": "L1ERC20Gateway",
            "isVerified": true,
            "address": "eth:0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0xf43bce5D32742FFC862eA182b0b5544CbDBB0F02"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567931,
                "transactionHash": "0x80b3040805a5b37638da6908f951e15306edabbf4773c7b53116daef4f72a04f",
                "implementations": [
                  "eth:0xf43bce5D32742FFC862eA182b0b5544CbDBB0F02"
                ]
              }
            ],
            "description": "Escrows deposited ERC-20 assets for the canonical Bridge. Upon depositing, a generic token representation will be minted at the destination. Withdrawals are initiated by the Outbox contract.",
            "url": "https://etherscan.io/address/0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0#code"
          },
          "chain": "ethereum",
          "includeInTotal": true,
          "chainId": 1
        },
        {
          "address": "0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B",
          "sinceTimestamp": 1777567931,
          "tokens": "*",
          "contract": {
            "name": "L1WethGateway",
            "isVerified": true,
            "address": "eth:0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B",
            "upgradeability": {
              "proxyType": "EIP1967 proxy",
              "admins": [
                "eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"
              ],
              "implementations": [
                "eth:0xa86996bED19547f7dEf22a087dD61b5F9Fb6C684"
              ]
            },
            "chain": "ethereum",
            "pastUpgrades": [
              {
                "timestamp": 1777567931,
                "transactionHash": "0x80b3040805a5b37638da6908f951e15306edabbf4773c7b53116daef4f72a04f",
                "implementations": [
                  "eth:0xa86996bED19547f7dEf22a087dD61b5F9Fb6C684"
                ]
              }
            ],
            "description": "Escrows WETH deposited through the canonical Bridge, minting a wrapped representation at the destination.",
            "url": "https://etherscan.io/address/0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B#code"
          },
          "chain": "ethereum",
          "includeInTotal": true,
          "chainId": 1
        }
      ],
      "programHashes": [
        {
          "title": "ArbOS wasmModuleRoot v61",
          "description": "A commitment to the exact WASM binary version used for Orbit stack optimistic dispute games.",
          "verificationStatus": "notVerified",
          "hash": "0xc10cd7ec6acaf1c441a3f6bd0900ad20f15855ba775a96f1939118cbc629dc97"
        }
      ],
      "risks": [
        {
          "category": "Funds can be stolen if",
          "text": "a contract receives a malicious code upgrade. There is no delay on code upgrades.",
          "isCritical": true
        },
        {
          "category": "Funds can be stolen if",
          "text": "the source code of unverified contracts contains malicious code.",
          "isCritical": true
        }
      ],
      "zkVerifiers": []
    }

  • discoveryInfo +7 -0 Viewed

    {
      "baseTimestamp": 1782988636,
      "contractsDiscoDriven": true,
      "hasDiscoUi": true,
      "isDiscoDriven": true,
      "permissionsDiscoDriven": true
    }

  • archivedAt +1 -0 Viewed

    null

  • hasTestnet +1 -0 Viewed

    null

• roninnetwork +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-optimium-superchain-opfp",
      "dataAvailability": [
        {
          "name": "Data is posted to EigenDA",
          "description": "Transactions roots are posted onchain and the full data is posted on EigenDA. The sequencer is publishing data to EigenDA v2. Since the DACert Verifier is not used, availability of the data is not verified against EigenDA operators, meaning that the Sequencer can single-handedly publish unavailable commitments.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the sequencer posts an unavailable transaction root.",
              "isCritical": true
            },
            {
              "category": "Funds can be lost if",
              "text": "the data is not available on the external provider.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "EigenDA Docs - Overview",
              "url": "https://docs.eigenda.xyz/overview"
            },
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x003A7A2d3129838Adb01c8d9b7DA62Ac6Ec27961#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        },
        {
          "name": "External bridge architecture",
          "description": "The May 2026 L2 migration deployed the OP Stack canonical bridge (OptimismPortal2 and L1StandardBridge) but did not migrate user funds into it; it is currently empty. User assets are custodied on two separate L1 paths, neither of which is the canonical bridge analyzed on this page: (1) Chainlink CCIP TokenPools, the active bridge since April 2025, securing 12 tokens including AXS, USDC, WETH, WBTC (new contract), YGG, PIXEL and SLP via Chainlink DON attestations and the Risk Management Network; (2) the legacy MainchainGateway, deprecated in April 2025 but still holding residual balances (legacy WBTC, ETH backing of legacy WETH, dust), withdrawable through the Ronin BridgeOperator stake-weighted multisig. Sky Mavis has not announced a plan to migrate liquidity into the OP Stack bridge.",
          "risks": [],
          "references": [
            {
              "title": "MainchainGateway - Etherscan",
              "url": "https://etherscan.io/address/0x64192819Ac13Ef72bF6b5AE239AC672B43a9AF08"
            },
            {
              "title": "Ronin Bridge to Chainlink CCIP migration - Ronin Blog",
              "url": "https://blog.roninchain.com/p/the-ronin-bridge-chainlink-ccip-migration"
            }
          ]
        },
        {
          "name": "Proof system cannot execute for this chain",
          "description": "The dispute games on this chain commit to the op-program v1.3.1 prestate (0x038512e0…6764d54c). That binary embeds the superchain-registry snapshot at commit 42bd03ba8313 (2024-08-21), which lists 17 chain IDs and does not include Ronin (chainId 2020). If a dispute game were stepped through to the VM, op-program's RollupConfigByChainID(2020) would not find a rollup config and would panic, producing an invalid output state — any claim (honest or fraudulent) could then be \"disproven\" against the panic. Users are not exposed today because the respected game type is PermissionedDisputeGame: only the proposer can create state proposals and only proposer/challenger can move or step. The proof system therefore reduces to an operator-attested delay timer rather than an adversarial fraud-proof. Fix would require redeploying games with either an updated registry snapshot or a chain-specific prestate.",
          "risks": [],
          "references": [
            {
              "title": "absolutePrestate hash registered in superchain-registry as op-program v1.3.1",
              "url": "https://github.com/ethereum-optimism/superchain-registry/blob/main/validation/standard/standard-prestates.toml"
            },
            {
              "title": "op-program v1.3.1 release (commit e3c2f04, 2024-08-23)",
              "url": "https://github.com/ethereum-optimism/optimism/releases/tag/op-program%2Fv1.3.1"
            },
            {
              "title": "superchain-registry snapshot pinned at op-program v1.3.1 build (42bd03ba8313)",
              "url": "https://github.com/ethereum-optimism/superchain-registry/blob/42bd03ba8313/chainList.json"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "opfp"
    }

• settlus +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-optimium-superchain-opfp",
      "dataAvailability": [
        {
          "name": "Data is posted to Celestia",
          "description": "Transactions roots are posted onchain and the full data is posted on Celestia.  Since the Blobstream bridge is not used, availability of the data is not verified against Celestia validators, meaning that the Sequencer can single-handedly publish unavailable roots.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the sequencer posts an unavailable transaction root.",
              "isCritical": true
            },
            {
              "category": "Funds can be lost if",
              "text": "the data is not available on the external provider.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Introducing Blobstream: streaming modular DA to Ethereum",
              "url": "https://blog.celestia.org/introducing-blobstream/"
            },
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x003E40D3125591bD722aB1bB880c78e4D74d0977#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• shape +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xfF00000000000000000000000000000000000360#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/shape.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/shape.json.zst).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• silentdata +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-optimium-superchain-opfp-preu16",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "The transaction data is not recorded on the Ethereum main chain.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x00a7a8fDb9A61f85DD8F926f4e1723927a18c9F3#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x2D7e764a0D9919e16983a46595CfA81fc34fa7Cd#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x2D7e764a0D9919e16983a46595CfA81fc34fa7Cd#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x2D7e764a0D9919e16983a46595CfA81fc34fa7Cd#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x2D7e764a0D9919e16983a46595CfA81fc34fa7Cd#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• snaxchain +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp-preu16",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xFeC57BD3729a5F930d4Ee8ac5992Fdc8988426e4#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/snax.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/snax.json.zst).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• soneium +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x008dC74CecC9dedA8595B2Fe210cE5979F0BfA8e#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/soneium.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/soneium.json.zst).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "opfp"
    }

• superlumio +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp-preu16",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xA12Cf34001e553dc254D131105364351f5174d75#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• superposition +7 -1 Viewed

  • scalingTechnology +7 -1 Viewed

    {
      "architectureImage": "orbit-optimium-fastconfirm",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 1 out of 1.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            },
            {
              "category": "Users can be censored if",
              "text": "the committee restricts their access to the external data."
            }
          ],
          "references": [
            {
              "title": "Inside AnyTrust - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/inside-anytrust"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular messaging",
          "description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
          "risks": [],
          "references": [
            {
              "title": "Transaction lifecycle - Arbitrum documentation",
              "url": "https://developer.offchainlabs.com/tx-lifecycle"
            },
            {
              "title": "L2 to L1 Messages - Arbitrum documentation",
              "url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
            },
            {
              "title": "Mainnet for everyone - Arbitrum Blog",
              "url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
            }
          ]
        },
        {
          "name": "Autonomous exit",
          "description": "Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.",
        "risks": [],
        "references": [
          {
            "title": "SequencerInbox.sol - source code, forceInclusion function",
            "url": "https://arbiscan.io/address/0xfEB2537afD8519d16d0CcEa741A70f97f3D4288B#code"
          },
          {
            "title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": [
          {
            "title": "Sequencer - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.",
          "risks": [],
          "references": [
            {
              "title": "Inside Arbitrum Nitro",
              "url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Buffered forced transactions",
        "description": "To force transactions from the host chain, users must first enqueue \"delayed\" messages in the \"delayed\" inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the `sendMessage` or `sendMessageFromOrigin` functions. If the centralized sequencer doesn't process the request within some time bound, users can call the `forceInclusion` function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn't timely process a message. Only messages processed with a delay greater than 428424622y 1mo consume the buffer. The buffer is capped at 428424622y 1mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 428424622y 1mo.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as \"assertions\" within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the `stakeOnNewAssertion` function. The stake is currently set to 0.1 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without \"rivals\" can be confirmed after the challenge period has passed, currently set to 5d 14h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.",
            "risks": [],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "BoLD paper",
                "url": "https://arxiv.org/pdf/2404.10491"
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the `createLayerZeroEdge` function in the `ChallengeManager` contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent \"history root\" that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 5d 14h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 11d 4h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.1 ETH, level 2 requires a stake of 0.1 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "an attacker successfully performs a resource exhaustion attack."
              }
            ],
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum BoLD",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "bold",
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• superseed +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x8612014a343089F1ddBACfD42baf4Afbf9133593#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://api.conduit.xyz/file/v1/optimism/rollup/superseed-mainnet-0).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://api.conduit.xyz/file/v1/optimism/genesis/superseed-mainnet-0).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• swell +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x005dE5857e38dFD703a1725c0900E9C6f24cbdE0#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/swell.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/swell.json.zst).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• unichain +2 -1 Viewed

  • scalingTechnology +2 -1 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp-permissionless",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xFf00000000000000000000000000000000000130#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/unichain.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/unichain.json.zst).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by anyone who has sufficient funds. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.08 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ]
            ],
            "risks": []
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 691.43 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "opfp"
    }

• worldchain +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0xff00000000000000000000000000000000000480#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/worldchain.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/worldchain.json.zst).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }

• zora +7 -0 Viewed

  • scalingTechnology +7 -0 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "dataAvailability": [
        {
          "name": "All data required for proofs is published on chain",
          "description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
          "risks": [],
          "references": [
            {
              "title": "Derivation: Batch submission - OP Mainnet specs",
              "url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
            },
            {
              "title": "BatchInbox - address",
              "url": "https://etherscan.io/address/0x6F54Ca6F6EdE96662024Ffd61BFd18f3f4e34DFf#code"
            },
            {
              "title": "OptimismPortal2.sol - source code, depositTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exits",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": [
            {
              "title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            },
            {
              "title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
              "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
            }
          ]
        },
        {
          "name": "Forced messaging",
          "description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": [
            {
              "title": "Forced withdrawal from an OP Stack blockchain",
              "url": "https://docs.optimism.io/stack/transactions/forced-transaction"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction",
        "description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
        "risks": [],
        "references": [
          {
            "title": "Sequencing Window - OP Mainnet Specs",
            "url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
          },
          {
            "title": "OptimismPortal2.sol - source code, depositTransaction function",
            "url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "EVM compatible smart contracts are supported",
          "description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
          "risks": [],
          "references": [
            {
              "title": "Introducing EVM Equivalence",
              "url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/zora.toml).",
        "compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
        "genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/tree/main/superchain/extra/genesis/mainnet).",
        "dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
      },
      "stateValidation": {
        "description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
            "references": [
              {
                "title": "OP stack specification: Fault Dispute Game",
                "url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
                "isCritical": true
              }
            ]
          },
          {
            "title": "Challenges",
            "description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
            "references": [
              {
                "title": "Fraud Proof Wars: OPFP",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      }
    }