Diff between 37a85921 (main) and 6b8d7da8 (PR)

• cyber +1 -1 Viewed

  • scalingTechnology +1 -1 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "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"
              }
            ]
          },
          {
            "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"
              }
            ]
          }
        ]
      }
    }

• funki +1 -1 Viewed

  • scalingTechnology +1 -1 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "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"
              }
            ]
          },
          {
            "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"
              }
            ]
          }
        ]
      }
    }

• hashkey +1 -1 Viewed

  • scalingTechnology +1 -1 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "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"
              }
            ]
          },
          {
            "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"
              }
            ]
          }
        ]
      }
    }

• lisk +1 -1 Viewed

  • scalingTechnology +1 -1 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "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"
              }
            ]
          },
          {
            "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"
              }
            ]
          }
        ]
      }
    }

• mint +1 -1 Viewed

  • scalingTechnology +1 -1 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "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"
              }
            ]
          },
          {
            "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 +1 -1 Viewed

  • scalingTechnology +1 -1 Viewed

    {
      "architectureImage": "opstack-optimium-superchain-opfp",
      "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"
              }
            ]
          },
          {
            "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 +1 -1 Viewed

  • scalingTechnology +1 -1 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "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"
              }
            ]
          },
          {
            "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"
              }
            ]
          }
        ]
      }
    }

• superlumio +1 -1 Viewed

  • scalingTechnology +1 -1 Viewed

    {
      "architectureImage": "opstack-rollup-superchain-opfp",
      "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"
              }
            ]
          },
          {
            "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"
              }
            ]
          }
        ]
      }
    }