Diff between f6b05548 (main) and dc1b81ca (PR)

• abstract +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-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": []
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the operator implements a TransactionFilterer, which is possible without delay."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
          }
        ]
      },
      "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": []
      },
      "stateDerivation": {
        "nodeSoftware": "The node software is open-source, and its source code can be found [here](https://github.com/matter-labs/zksync-era).\n    The main node software does not rely on Layer 1 (L1) to reconstruct the state, but you can use [this tool](https://github.com/eqlabs/zksync-state-reconstruct) for that purpose. Currently, there is no straightforward method to inject the state into the main node, but ZKsync is actively working on a solution for this.",
        "compressionScheme": "Bytecodes undergo compression before deployment on Layer 1 (L1). You can find additional information on this process [here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/advanced/11_compression.md).",
        "genesisState": "There have been neither genesis states nor regenesis.",
        "dataFormat": "Details on data format can be found [here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/advanced/09_pubdata.md)."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }

• adi +3 -1 Viewed

  • scalingTechnology +3 -1 Viewed

    {
      "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": []
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the operator implements a TransactionFilterer, which is possible without delay."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
          }
        ]
      },
      "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": []
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "MatterLabs proof system Airbender can be found [here](https://github.com/matter-labs/zksync-airbender/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The docs about the system can be found [here](https://github.com/matter-labs/zksync-airbender/blob/main/docs/README.md).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "\nUpgrades are managed by a Governance smart contract on L1. The owner of smart contract (eth:0xB272B188855128c10a933Edb62CC64c22B1f3754) can schedule either transparent or shadow proposals.\nTransparent proposals have full upgrade data onchain when scheduled. Shadow proposals post only the hash of the upgrade data onchain when proposed, and the full upgrade data during execution.\n\nScheduled proposals must wait a minimal delay before being executed (currently 0s). Governance supports a 'securityCouncil' role (eth:0x59Be28DE6eFb1f78802E96188d2b7907059Be59f) that can execute proposals without any delay.\n\nCurrently, the governance process does not involve ADI token holders. See this link for more info: [https://docs.adi.foundation/appendix/appendix-b-governance](https://docs.adi.foundation/appendix/appendix-b-governance).\n  "
      "upgradesAndGovernance": {
        "content": "\nUpgrades are managed by a Governance smart contract on L1. The owner of smart contract (eth:0xB272B188855128c10a933Edb62CC64c22B1f3754) can schedule either transparent or shadow proposals.\nTransparent proposals have full upgrade data onchain when scheduled. Shadow proposals post only the hash of the upgrade data onchain when proposed, and the full upgrade data during execution.\n\nScheduled proposals must wait a minimal delay before being executed (currently 0s). Governance supports a 'securityCouncil' role (eth:0x59Be28DE6eFb1f78802E96188d2b7907059Be59f) that can execute proposals without any delay.\n\nCurrently, the governance process does not involve ADI token holders. See this link for more info: [https://docs.adi.foundation/appendix/appendix-b-governance](https://docs.adi.foundation/appendix/appendix-b-governance).\n  "
      }
    }

• arbitrum +3 -1 Viewed

  • scalingTechnology +3 -1 Viewed

    {
      "architectureImage": "arbitrumwithbold",
      "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/0x98a58ADAb0f8A66A1BF4544d804bc0475dff32c7#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 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 30m 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 30m.",
        "references": [
          {
            "title": "Sequencer and censorship resistance - Arbitrum documentation",
            "url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
          }
        ],
        "risks": []
      },
      "stateDerivation": {
        "nodeSoftware": "The rollup node (Arbitrum Nitro) consists of four parts. The base layer is the core Geth server (with minor modifications to add hooks) that emulates the execution of EVM contracts and maintains Ethereum's state and [a fork of wasmer](https://github.com/OffchainLabs/wasmer) that is used for native WASM execution. The middle layer, ArbOS, provides additional Layer 2 functionalities such as decompressing data batches, accounting for Layer 1 gas costs, and supporting cross-chain bridge functionalities. The top layer consists of node software, primarily from Geth, that handles client connections (i.e., regular RPC node). [View Code](https://github.com/OffchainLabs/nitro/)",
        "compressionScheme": "The Sequencer's batches are compressed using a general-purpose data compression algorithm known as [Brotli](https://github.com/google/brotli), configured to its highest compression setting.",
        "genesisState": "They performed a regenesis from Classic to Nitro, and that file represents the [last Classic state](https://snapshot.arbitrum.foundation/arb1/nitro-genesis.tar). To sync from the initial Classic state, instructions can be found [here](https://docs.arbitrum.io/migration/state-migration).",
        "dataFormat": "Nitro supports Ethereum's data structures and formats by incorporating the core code of the popular go-ethereum (\"Geth\") Ethereum node software. The batch is composed of a header and a compressed blob, which results from compressing concatenated RLP-encoded transactions using the standard RLP encoding."
      },
      "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": "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 3600.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": [],
            "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 555.0 ETH, level 2 requires a stake of 79.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": "\nAll 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."
      "upgradesAndGovernance": {
        "content": "\nAll 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."
      }
    }

• astarzkevm +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-validium",
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "There is no general mechanism to force the sequencer to include the transaction.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, forceBatchAddress address",
            "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "Only a trusted sequencer is allowed to submit transaction batches.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          },
          {
            "category": "Funds can be frozen if",
            "text": "the sequencer refuses to include an exit transaction.",
            "isCritical": true
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, onlyTrustedSequencer modifier",
            "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation.",
        "compressionScheme": "No compression scheme is used.",
        "genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
        "dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/tools/zkevm/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
          },
          {
            "title": "ZK Circuits",
            "description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
          },
          {
            "title": "Pessimistic Proofs",
            "description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
          },
          {
            "title": "Validity proofs",
            "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
            "risks": [],
            "references": [
              {
                "title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
                "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• aztecnetwork +3 -1 Viewed

  • scalingTechnology +3 -1 Viewed

    {
      "dataAvailability": [
        {
          "name": "All transaction results (state diffs) are published in Ethereum blobs",
          "description": "Each checkpoint proposal includes EIP-4844 blob commitments that are checked against the blob hashes in the proposing transaction. The epoch proof revalidates the accumulated blob commitments before the epoch is finalized.",
          "references": [
            {
              "title": "Rollup.sol - propose() on Etherscan",
              "url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
            },
            {
              "title": "Rollup.sol - validateBlobs() on Etherscan",
              "url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
            }
          ],
          "risks": []
        }
      ],
      "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. ZK proofs are required to settle blocks. Once the epoch root proof has been verified, the rollup inserts the epoch root into the Outbox, from which withdrawals and other L2->L1 messages can be consumed on Ethereum. Withdrawals can be initiated privately on L2, revealing only the L1-facing portion of the transaction. There is no canonical bridge escrow: only the canonical messaging layer is immutable, while each token bridged through a locking escrow may introduce additional trust assumptions tied to that specific escrow.",
          "risks": [],
          "references": [
            {
              "title": "Rollup.sol - submitEpochRootProof() on Etherscan",
              "url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
            },
            {
              "title": "Outbox.sol - consume() on Etherscan",
              "url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#code"
            }
          ]
        }
      ],
      "operator": {
        "name": "There is no central operator",
        "description": "There is no privileged sequencer. Anyone can stake 200 K AZTEC to join the sequencer queue, and anyone can call flushEntryQueue() to activate queued sequencers once the queue rules allow it.",
        "risks": [],
        "references": [
          {
            "title": "Rollup.sol - deposit() on Etherscan",
            "url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
          },
          {
            "title": "Rollup.sol - flushEntryQueue() on Etherscan",
            "url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "Upgrades replace the canonical rollup",
          "description": "The core contracts are immutable, but Governance owns the Registry and GSE and can register a new rollup version as canonical after the governance delay. Governance also owns critical config parameters that can freeze or compromise the Rollup system.",
          "references": [
            {
              "title": "Registry.sol - addRollup() on Etherscan",
              "url": "https://etherscan.io/address/0x35b22e09Ee0390539439E24f06Da43D83f90e298#code"
            },
            {
              "title": "Governance.sol - execute() on Etherscan",
              "url": "https://etherscan.io/address/0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e#code"
            }
          ],
          "risks": []
        },
        {
          "name": "No canonical bridge escrow",
          "description": "There is no default canonical escrow. The rollup is deployed only with an immutable canonical messaging bridge, which can be used by any escrow. As a result, each token bridged to Aztec via Ethereum lock-mint must be assessed individually by examining its specific locking escrow. The trust assumptions of a given escrow may differ from those of the immutable rollup itself. Gas tokens are bridged through the FeeJuicePortal, an immutable one-way portal that only supports bridging to public L2 addresses. Although the rollup and its canonical messaging bridge are immutable, an upgradeable escrow could migrate its funds to a new rollup version without requiring users to migrate, effectively trading immutability for convenience.",
          "references": [
            {
              "title": "FeeJuicePortal.sol - on Etherscan",
              "url": "https://etherscan.io/address/eth:0x2891F8b941067F8B5a3F34545A30Cf71E3E23617#code"
            },
            {
              "title": "Outbox.sol - on Etherscan",
              "url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#code"
            }
          ],
          "risks": []
        },
        {
          "name": "Inclusion is probabilistic",
          "description": "All censorship resistance tools that are part of the protocol rely on probabilistic inclusion. In contrast to \"forced transactions\", there is no simple deterministic inclusion after some maximum delay, but rather different inclusion probabilities after different time horizons. The \"time needed to exit\" of 20d for the exit window was simulated by using a simple model of the decentralized sequencer set at launch. The escape hatch and private transactions can give additional inclusion guarantees.",
          "references": [
            {
              "title": "CRsim - Simulated inclusion probability on Aztec",
              "url": "https://sekuba.github.io/crsim"
            }
          ],
          "risks": []
        }
      ],
      "sequencing": {
        "name": "Transactions are ordered by a staked committee",
        "description": "Joining the sequencer set is permissionless and requires staking 200 K AZTEC. For each epoch, the rollup samples a 48-member committee from the active sequencer set of 3548 and selects one proposer per slot. The committee and regular sequencer set can be circumvented via the escape hatch, which designates a bonded proposer (via RANDAO) who can publish checkpoints without committee attestations.",
        "references": [
          {
            "title": "Rollup.sol - getProposerAt() on Etherscan",
            "url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
          },
          {
            "title": "EscapeHatch.sol - selectCandidates() on Etherscan",
            "url": "https://etherscan.io/address/0x8c189ead28D5987A48e522162f9225124D50AD1B#code"
          }
        ],
        "risks": []
      },
      "stateValidation": {
        "description": "Each epoch root proof is verified by the HonkVerifier smart contract on Ethereum before the proven checkpoint number is advanced and the epoch outbox state root is inserted into the Outbox. Proving is permissionless, and a single proof can cover one Checkpoint (1m 12s) to one epoch (38m 24s). Unproven checkpoints are pruned after the proof submission window of 1h 16m expires.",
        "categories": [
          {
            "title": "State root proposals",
            "description": "The rollup only advances the proven chain after submitEpochRootProof() succeeds. That call verifies the epoch proof and then inserts the epoch outbox state root for L2->L1 messaging.",
            "references": [
              {
                "title": "Rollup.sol - submitEpochRootProof() on Etherscan",
                "url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
              }
            ],
            "risks": []
          },
          {
            "title": "Validity proofs",
            "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
            "risks": [],
            "references": [
              {
                "title": "Rollup.sol - submitEpochRootProof() on Etherscan",
                "url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
              },
              {
                "title": "HonkVerifier.sol - verify() on Etherscan",
                "url": "https://etherscan.io/address/0x70aEDda427f26480D240bc0f4308ceDec8d31348#code"
              }
            ]
          },
          {
            "title": "Slashing",
            "description": "\nEach stake of 200 K AZTEC that is locked to join the sequencer set and vote in governance can be slashed under certain conditions. Slashing is voted on by sequencers each time they propose a checkpoint and is grouped in rounds that span 4 epochs (2h 33m) each.\n\nSlashing conditions are programmed into each sequencer node and can be changed by node operators by updating or editing their node software. Nodes usually submit votes to slash automatically on L1. The `TallySlashingProposer` contract only enforces the formalities of the slashing system:\n* A given slashing round's votes always target the checkpoint proposals from 2 rounds ago.\n* As soon as a round's votes have reached a quorum of 65/128, it enters an execution delay of 28 rounds (2d 23h)\n* An automatically generated slashing payload is executable by anyone on L1 after the execution delay, applying the slashing penalties defined by the sequencer votes.\n\nSlashing penalties are defined onchain in three levels: large (2.00 K AZTEC), medium (2.00 K AZTEC), and small (2.00 K AZTEC). Offenses that lead to slashing usually include:\n* Inactivity: A sequencer fails to attest or propose when selected.\n* Data Withholding: A sequencer proposes a checkpoint including state diff data availability on L1 but withholds the public transaction bodies and/or CHONK proofs required for permissionless proving.\n* Invalidity: A sequencer attests to invalid proposals, multiple conflicting proposals, with invalid signatures, or proposes a block that is not proven in time.\n\nThe above offense list is not exhaustive and not defined onchain but usually in the software the sequencers decide to run. This is also where the mapping of offenses to the slashing penalty levels can be defined.\n\nThe SlashVeto Council is a 5/9 Multisig that can veto specific proposals and/or all slashing for 3d at a time.",
            "references": [
              {
                "title": "Slashing - Aztec Docs",
                "url": "https://docs.aztec.network/operate/operators/sequencer-management/slashing_and_offenses"
              },
              {
                "title": "SlashVeto Council - Github",
                "url": "https://github.com/aztec-slash-veto/council"
              },
              {
                "title": "slashveto.me - Monitor Slashing",
                "url": "https://slashveto.me"
              }
            ],
            "risks": []
          }
        ]
      },
      "upgradesAndGovernance": "\n# Standard Path (Signaling)\nBecause sequencers stake AZTEC tokens to secure the L2 network, they are also the primary governors of the system. Any governance proposal must be encoded and deployed as a smart contract payload on Ethereum. While core contracts are immutable, the onchain Governance system can designate a new 'canonical' rollup with a 1mo delay and has access to critical configuration permissions that can freeze or compromise the Rollup system. These permissions can only be accessed through the process described below.\n\n## 1. The Signaling Phase (`GovernanceProposer`)\nAztec uses an onchain \"Empire\" signaling system. Active sequencers operating on the 'canonical rollup' (as defined by the Registry) call `signal(payloadAddress)` on the L1 `GovernanceProposer` contract during their designated L2 slots to support a specific upgrade payload. A voting round consists of 1,000 slots. To win a round and become a formal proposal, a payload must receive signals from at least 600 slots. Once quorum is reached, the payload is submitted to the L1 `Governance` contract.\n\n## 2. The Voting Phase (`Governance`)\nOnce submitted, the proposal enters a delay and voting flow:\n*   **Pending (3d):** At the end of this delay, voting power is snapshotted.\n*   **Active (7d):** AZTEC token holders can vote. To pass, a proposal must reach a 20% Quorum of all staked power, and the `yea` votes must exceed a required margin of 33%.\n*   **Queued (1mo):** If successful, the proposal enters an execution delay. This acts as an exit window, allowing dissenting sequencers to initiate a withdrawal of their staked tokens before the malicious/disagreed-upon code is executed.\n*   Executable (7d): The proposal enters a grace period where anyone can call `execute()`. If not executed, it expires.\n\nTotal standard delay from proposal to execution: **1mo 10d**.\n\n### Emergency Path (Circumvent Signaling)\nIf the L2 sequencer set is offline, censoring, or acting maliciously, the `GovernanceProposer` cannot be used. To ensure liveness, anyone can bypass the Sequencer signaling phase using the `proposeWithLock()` function directly on the `Governance` contract.\n*   An actor must lock **258 M AZTEC**, roughly 2.5% of total supply\n*   These funds are locked for an extended 3mo.\n*   Once proposed, the payload enters the exact same 1mo 10d Voting Phase (Pending -> Active -> Queued -> Executable) as the standard path.\n\n### Rollup Immutability\nThe smart contract code of `Rollup`, its verifier and its canonical messaging contracts cannot be changed. However, `Governance` owns critical permissions for configuration parameters that can freeze the L2 indefinitely. 'Upgrading' a Rollup contract involves a `Governance` action that designates a new `Rollup` contract address as canonical. The `GSE` (Governance Staking Escrow) automatically migrates the voting power and stake of all active sequencers to the new rollup version if they staked to the default magic address `0x9064Fb41156D300196d5Eb95E0B3c1f08eBc39a8` instead of a specific immutable rollup. Importantly, `Governance` retains ownership of the old rollup, with the permissions to freeze it in the same or any future governance proposal. In summary and practice, the current Aztec rollup system is not immutable and prone to governance changes with the configured 1mo delay.\n\n### Slashing and the SlashVeto Council\nAztec features onchain slashing for equivocation or missing attestations, managed by `Slasher` and `TallySlashingProposer`. \n\nThere is a protective **Vetoer** role held by the SlashVeto Council. The Council cannot upgrade the protocol, alter governance, or steal funds. Instead it is limited to two permissions:\n*   call `vetoPayload()` to stop a specific slashing event.\n*   call `setSlashingEnabled(false)`, which pauses all slashing in the protocol for a period of 3d.\n\n### Economics & Treasury\n*   **Coin Issuer:** The `CoinIssuer` contract is owned by Governance and is authorized to mint new AZTEC tokens up to a cap of 20%.\n*   **Protocol Treasury:** Funds owned by the DAO sit in the `ProtocolTreasury`. The Treasury has a hardcoded timestamp (approx. Nov 2026). Before this date, the DAO cannot spend Treasury funds. After this date, Treasury funds and token ownership can be moved with a Governance Proposal.",
      "upgradesAndGovernance": {
        "content": "\n# Standard Path (Signaling)\nBecause sequencers stake AZTEC tokens to secure the L2 network, they are also the primary governors of the system. Any governance proposal must be encoded and deployed as a smart contract payload on Ethereum. While core contracts are immutable, the onchain Governance system can designate a new 'canonical' rollup with a 1mo delay and has access to critical configuration permissions that can freeze or compromise the Rollup system. These permissions can only be accessed through the process described below.\n\n## 1. The Signaling Phase (`GovernanceProposer`)\nAztec uses an onchain \"Empire\" signaling system. Active sequencers operating on the 'canonical rollup' (as defined by the Registry) call `signal(payloadAddress)` on the L1 `GovernanceProposer` contract during their designated L2 slots to support a specific upgrade payload. A voting round consists of 1,000 slots. To win a round and become a formal proposal, a payload must receive signals from at least 600 slots. Once quorum is reached, the payload is submitted to the L1 `Governance` contract.\n\n## 2. The Voting Phase (`Governance`)\nOnce submitted, the proposal enters a delay and voting flow:\n*   **Pending (3d):** At the end of this delay, voting power is snapshotted.\n*   **Active (7d):** AZTEC token holders can vote. To pass, a proposal must reach a 20% Quorum of all staked power, and the `yea` votes must exceed a required margin of 33%.\n*   **Queued (1mo):** If successful, the proposal enters an execution delay. This acts as an exit window, allowing dissenting sequencers to initiate a withdrawal of their staked tokens before the malicious/disagreed-upon code is executed.\n*   Executable (7d): The proposal enters a grace period where anyone can call `execute()`. If not executed, it expires.\n\nTotal standard delay from proposal to execution: **1mo 10d**.\n\n### Emergency Path (Circumvent Signaling)\nIf the L2 sequencer set is offline, censoring, or acting maliciously, the `GovernanceProposer` cannot be used. To ensure liveness, anyone can bypass the Sequencer signaling phase using the `proposeWithLock()` function directly on the `Governance` contract.\n*   An actor must lock **258 M AZTEC**, roughly 2.5% of total supply\n*   These funds are locked for an extended 3mo.\n*   Once proposed, the payload enters the exact same 1mo 10d Voting Phase (Pending -> Active -> Queued -> Executable) as the standard path.\n\n### Rollup Immutability\nThe smart contract code of `Rollup`, its verifier and its canonical messaging contracts cannot be changed. However, `Governance` owns critical permissions for configuration parameters that can freeze the L2 indefinitely. 'Upgrading' a Rollup contract involves a `Governance` action that designates a new `Rollup` contract address as canonical. The `GSE` (Governance Staking Escrow) automatically migrates the voting power and stake of all active sequencers to the new rollup version if they staked to the default magic address `0x9064Fb41156D300196d5Eb95E0B3c1f08eBc39a8` instead of a specific immutable rollup. Importantly, `Governance` retains ownership of the old rollup, with the permissions to freeze it in the same or any future governance proposal. In summary and practice, the current Aztec rollup system is not immutable and prone to governance changes with the configured 1mo delay.\n\n### Slashing and the SlashVeto Council\nAztec features onchain slashing for equivocation or missing attestations, managed by `Slasher` and `TallySlashingProposer`. \n\nThere is a protective **Vetoer** role held by the SlashVeto Council. The Council cannot upgrade the protocol, alter governance, or steal funds. Instead it is limited to two permissions:\n*   call `vetoPayload()` to stop a specific slashing event.\n*   call `setSlashingEnabled(false)`, which pauses all slashing in the protocol for a period of 3d.\n\n### Economics & Treasury\n*   **Coin Issuer:** The `CoinIssuer` contract is owned by Governance and is authorized to mint new AZTEC tokens up to a cap of 20%.\n*   **Protocol Treasury:** Funds owned by the DAO sit in the `ProtocolTreasury`. The Treasury has a hardcoded timestamp (approx. Nov 2026). Before this date, the DAO cannot spend Treasury funds. After this date, Treasury funds and token ownership can be moved with a Governance Proposal."
      },
      "warning": "Aztec v4 has [know security vulnerabilities](https://aztec.network/blog/critical-vulnerability-in-alpha-v4) that can only be fixed in a new deployment."
    }

• base +3 -1 Viewed

  • scalingTechnology +3 -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/0xFf00000000000000000000000000000000008453#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/base.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://raw.githubusercontent.com/base-org/node/refs/tags/v0.8.4/mainnet/genesis-l2.json).",
        "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"
              }
            ]
          },
          {
            "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": "All contracts are upgradable by a `ProxyAdmin` contract controlled by a nested 2/2 `Base Governance Multisig` composed of the `Base Coordinator Multisig` and the `Base Security Council`. Upgrades require approval from both parties. There is no delay on upgrades. The Guardian role for the SuperchainConfig is assigned to the Base Governance Multisig, which can pause and unpause withdrawals. `Base Multisig 1` serves as Incident Responder and can pause withdrawals but cannot unpause or extend pauses. Each pause automatically expires after 3 months if not extended by the Guardian. The single Sequencer actor can be modified by `Base Multisig 1` via the SystemConfig contract. The Base Governance multisig can also recover dispute bonds in case of bugs that would distribute them incorrectly."
      "upgradesAndGovernance": {
        "content": "All contracts are upgradable by a `ProxyAdmin` contract controlled by a nested 2/2 `Base Governance Multisig` composed of the `Base Coordinator Multisig` and the `Base Security Council`. Upgrades require approval from both parties. There is no delay on upgrades. The Guardian role for the SuperchainConfig is assigned to the Base Governance Multisig, which can pause and unpause withdrawals. `Base Multisig 1` serves as Incident Responder and can pause withdrawals but cannot unpause or extend pauses. Each pause automatically expires after 3 months if not extended by the Guardian. The single Sequencer actor can be modified by `Base Multisig 1` via the SystemConfig contract. The Base Governance multisig can also recover dispute bonds in case of bugs that would distribute them incorrectly."
      }
    }

• cronoszkevm +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-validium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "The transaction data is not recorded on the Ethereum main chain. Transaction data is stored off-chain and only the hashes are posted onchain by the centralized Sequencer.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "ExecutorFacet - _commitOneBatch() function",
              "url": "https://etherscan.io/address/0x0597CaA8A823A699d7CD9E62B5E5d4153FF82691#code#F1#L60"
            }
          ]
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the operator implements a TransactionFilterer, which is possible without delay."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
          }
        ]
      },
      "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": []
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }

• forknet +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-opstack_closed",
      "dataAvailability": [
        {
          "name": "Data is posted on Ethereum",
          "description": "Transaction data is posted to Ethereum L1 as compressed calldata or blobs through the OP Stack batch inbox.",
          "risks": [],
          "references": []
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "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": []
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            },
            {
              "category": "Funds can be stolen if",
              "text": "the operator manipulates the L2 state, which is not validated on Ethereum.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• gpt +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-validium",
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "There is no general mechanism to force the sequencer to include the transaction.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, forceBatchAddress address",
            "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "Only a trusted sequencer is allowed to submit transaction batches.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          },
          {
            "category": "Funds can be frozen if",
            "text": "the sequencer refuses to include an exit transaction.",
            "isCritical": true
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, onlyTrustedSequencer modifier",
            "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "Node software can be found [here](https://github.com/0xPolygon/cdk-validium-node).",
        "compressionScheme": "No compression scheme yet.",
        "genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `getRollupBatchNumToStateRoot(5,0)` method of AgglayerManager, is available [here](https://github.com/0xPolygonHermez/zkevm-contracts/blob/1ad7089d04910c319a257ff4f3674ffd6fc6e64e/tools/addRollupType/genesis.json).",
        "dataFormat": "The trusted sequencer request signatures from DAC members off-chain, and posts hashed batches with signatures to the GptProtocolValidium contract."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
          },
          {
            "title": "ZK Circuits",
            "description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
          },
          {
            "title": "Pessimistic Proofs",
            "description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
          },
          {
            "title": "Validity proofs",
            "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
            "risks": [],
            "references": [
              {
                "title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
                "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• grvt +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-validium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "The transaction data is not recorded on the Ethereum main chain. Transaction data is stored off-chain and only the hashes are posted onchain by the centralized Sequencer.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "ExecutorFacet - _commitOneBatch() function",
              "url": "https://etherscan.io/address/0x0597CaA8A823A699d7CD9E62B5E5d4153FF82691#code#F1#L50"
            }
          ]
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can't force all transactions",
        "description": "If a user is censored by the L2 Sequencer, they cannot by default force their transaction via the L1 queue. An active TransactionFilterer contract which allows only whitelisted accounts to enqueue, prevents it. Even if a user was specifically whitelisted, there is no mechanism that forces L2 Sequencer to include            transactions from the queue in an L2 block, as they have the choice to process the queue in order or not at all.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the Operator does not specifically whitelist them in the TransactionFilterer."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/rollup/l1_l2_communication#priority-operations-1"
          },
          {
            "title": "Mailbox facet",
            "url": "https://etherscan.io/address/0x1e34aB39a9682149165ddeCc0583d238A5448B45#code#F1#L472"
          },
          {
            "title": "TransactionFilterer",
            "url": "https://etherscan.io/address/0x8319fede99061c6723c86d366a903e8fa3a0f541#code#F1#L29"
          }
        ]
      },
      "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": []
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }

• haust +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-pessimistic",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Transaction data is kept off-chain. Bridge accounting is protected by pessimistic proofs while L2 state transitions are not proven on Ethereum.",
          "risks": [],
          "references": []
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "There is no general mechanism to force the sequencer to include the transaction.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            },
            {
              "category": "Funds can be stolen if",
              "text": "the operator manipulates the L2 state, which is not validated on Ethereum.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• katana +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "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": [
            {
              "url": "https://etherscan.io/address/0x000d4411cdeb152378626B5C5E33fd5D6808939a",
              "title": "batchInbox - Etherscan address"
            }
          ]
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "The mechanism for allowing users to submit their own transactions is currently disabled.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": [
          {
            "url": "https://etherscan.io/address/0x3e6753e6c0162061cfa7eEc88d8fdaE651160Bf4#code#F1#L563",
            "title": "_depositTransaction() in OptimismPortal2 - Etherscan source code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized operator",
        "description": "Only a trusted sequencer is allowed to submit transaction batches. A mechanism for users to submit their own batches is currently disabled. Only a trusted proposer can propose and prove new state roots.",
        "risks": [
          {
            "category": "Funds can be frozen if",
            "text": "the permissioned proposer fails to publish state roots to the L1."
          },
          {
            "category": "Funds can be frozen if",
            "text": "the permissioned sequencer fails to publish transaction data to the L1."
          }
        ],
        "references": [
          {
            "url": "https://etherscan.io/address/0xb6e1f8B589A14B79DDD3aD7F0589AB548c70C174#readProxyContract#F13",
            "title": "batcherHash - Etherscan address"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains ('cdk-sovereign' and aggchains). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum or custom proof systems are able to share the bridge with the zkEVM Agglayer projects.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.agglayer.dev/agglayer/core-concepts/pessimistic-proof/"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "stateValidation": {
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "Katana uses the Agglayer CDK in CDK-opgeth-zkrollup configuration. This combines an OP-Succinct zk rollup base with Agglayer shared bridge interoperability. Both parts are verified in a single nested proof using the Succinct Sp1Verifier. This proof is called the pessimistic proof by Agglayer which contains 1) the bridge accounting proof proving only the secure accounting of the Agglayer shared bridge and can have 2) a reference to an 'aggchain proof', which can define additional programs to be proven. In the case of Katana, these are the op-succinct block range proofs as an aggregated proof proving the state transitions of the L2.",
            "references": [
              {
                "url": "https://docs.agglayer.dev/cdk/cdk-opgeth/architecture/#cdk-opgeth-zkrollup-not-live-yet",
                "title": "CDK-opgeth-zkrollup architecture"
              }
            ]
          },
          {
            "title": "Validity proofs",
            "description": "Each update to the rollup state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
            "references": [
              {
                "url": "https://succinctlabs.github.io/op-succinct/architecture.html",
                "title": "Op-Succinct architecture"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "the state transition validity proof cryptography is broken or implemented incorrectly."
              },
              {
                "category": "Funds can be stolen if",
                "text": "A malicious state transition is finalized by activating the permissioned optimistic mode."
              },
              {
                "category": "Funds can be stolen if",
                "text": "the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route id."
              },
              {
                "category": "Funds can be frozen if",
                "text": "the AggLayerGateway is unable to route proof verification to a valid verifier."
              }
            ]
          },
          {
            "title": "Pessimistic Proofs",
            "description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge (minimum security guarantee) are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1).",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "the pessimistic proof cryptography is broken or implemented incorrectly."
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "\nThe regular upgrade process for all system contracts (shared and L2-specific) starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific rollup- or validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Layer 2 can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Finally, it can manage SP1 verification keys for pessimistic proofs and aggchain proofs, which defines the affected chains' state validation. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for all system contracts (shared and L2-specific) starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific rollup- or validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Layer 2 can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Finally, it can manage SP1 verification keys for pessimistic proofs and aggchain proofs, which defines the affected chains' state validation. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• kinto +3 -1 Viewed

  • scalingTechnology +3 -1 Viewed

    {
      "architectureImage": "kinto",
      "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/0xa5E09FfA33dd011F5B68aAA55F513D6773579f78#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": [
            {
              "title": "List of whitelisted Kinto validators",
              "url": "https://docs.kinto.xyz/kinto-the-modular-exchange/security-kyc-aml/kinto-validators"
            }
          ]
        }
      ],
      "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/0xa5E09FfA33dd011F5B68aAA55F513D6773579f78#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": "Enforced smart wallets and KYC",
          "description": "\n      The Kinto L2 node is a fork of Arbitrum's geth implementation with notable changes to the state transition function.\n      A valid state transition in Kinto [disallows all transactions by EOAs](https://github.com/KintoXYZ/kinto-go-ethereum/blob/7aba9b812a82d9339d29a2345946c3d7030a0377/core/kinto_hardfork_7.go#L58) and new contract creation, unless specifically whitelisted.\n      The current whitelist is sourced directly from the KintoAppRegistry smart contract on Kinto L2, and can be modified by the L2 governance.\n      This setup effectively enforces smart wallet use because the auxiliary contracts of the standard KintoWallet smart wallet (like the EntryPoint and the KintoWalletFactory) are whitelisted.\n\n      The KYC validation is part of the KintoWallet signature verification. Since all users must use the same implementation of this smart wallet, all user transactions on Kinto check for an up-to-date KYC flag, and are dropped in case the check fails.",
          "risks": [
            {
              "category": "Users can be censored if",
              "text": "a KYC provider changes the users' KYC status and the Security Council confirms it."
            },
            {
              "category": "Funds can be lost if",
              "text": "the user interacts with a compromised whitelisted contract."
            }
          ],
          "references": [
            {
              "title": "User Owned KYC - Kinto documentation",
              "url": "https://docs.kinto.xyz/kinto-the-safe-l2/security-kyc-aml/how-does-kinto-solve-it"
            }
          ]
        }
      ],
      "sequencing": {
        "name": "Delayed 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 hardcoded to be 1d.",
        "references": [],
        "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": "Whitelisted validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. This structure forms a graph, and therefore, in the contracts, state roots are referred to as nodes. Each proposal requires a stake, currently set to 0.1 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be moved from one node to one of its children, either by calling `stakeOnExistingNode` or `stakeOnNewNode`. New nodes cannot be created faster than the minimum assertion period by the same validator, currently set to 15m. The oldest unconfirmed node can be confirmed if the challenge period has passed and there are no siblings, and rejected if the parent is not a confirmed node or if the challenge period has passed and no one is staked on it.",
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "none of the whitelisted verifiers checks the published state. Fraud proofs assume at least one honest and able validator.",
                "isCritical": true
              }
            ],
            "references": [
              {
                "title": "How is fraud proven - Arbitrum documentation FAQ",
                "url": "https://docs.arbitrum.io/get-started/arbitrum-introduction"
              }
            ]
          },
          {
            "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 `startChallenge` function. Validators cannot be in more than one challenge at the same time, meaning that the protocol operates with [partial concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Since each challenge lasts 6d 8h, this implies that the protocol can be subject to [delay attacks](https://medium.com/offchainlabs/solutions-to-delay-attacks-on-rollups-434f9d05a07a), where a malicious actor can delay withdrawals as long as they are willing to pay the cost of losing their stakes. If the protocol is delayed attacked, the new stake requirement increases exponentially for each challenge period of delay. Challenges are played via a bisection game, where asserter and challenger play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner, who then gets half of the stake of the loser. As said before, a state root is rejected only when no one left is staked on it. The protocol does not enforces valid bisections, meaning that actors can propose correct initial claim and then provide incorrect midpoints.",
            "references": [
              {
                "title": "Fraud Proof Wars: Arbitrum Classic",
                "url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
              }
            ]
          }
        ]
      },
      "stateValidationImage": "orbit",
      "upgradesAndGovernance": "\nAll critical system smart contracts are upgradeable (can be arbitrarily changed). This permission is held by the 6/8 Kinto Security Council on Layer 1 and can be executed without any delay.\nOn the Kinto Layer 2, critical permissions are mostly guarded by an AccessManager contract, and then passed down with configurable delays to both the Security Council and the 2/4 Kinto Multisig 2.\n\nThe Appchain designation of Kinto is mainly due to a modified L2 node, which queries a special censoring contract on L2 (called KintoAppRegistry) for a whitelist to filter transactions.\nThis makes the KintoAppRegistry contract a critical system contract and any change to its configuration equivalent to an upgrade of the Layer 2 system.\nThe KintoAppRegistry contract is also governed via the AccessManager by the Security Council or the Kinto Multisig 2 with a 12d delay.\n\nAnother critical contract on the Appchain is called KintoID. Permissioned actors with the 'KYC provider' role in the KintoID contract can 'sanction' (freeze) user smart wallets, preventing them from transacting.\nTo protect users from this role which is mostly held by EOAs, a sanction expires if not confirmed by the Security Council within 3d.\nAn expired sanction guarantees the user a 9d cooldown window during which they cannot be sanctioned again.\n\nThe canonical (enforced) smartwallet for users on Kinto can be upgraded via the KintoWalletFactory, using the same path via the AccessManager.\nAdditionally, each smart wallet must use a recoverer address custodied by Turnkey. This allows users to reset the wallet signers via their email in case they lose their passkey.\nIt also necessitates a recovery delay to prevent turnkey from maliciously using their recoverer permission. During this period of 12d, the user can cancel the recovery process with any transaction in their smart wallet.\n\nThe permissioned sanctions logic by KYC providers necessitates at least an 12d delay on all upgrades that aren't executed by the Security Council, allowing the user at least 7d to exit.",
      "upgradesAndGovernance": {
        "content": "\nAll critical system smart contracts are upgradeable (can be arbitrarily changed). This permission is held by the 6/8 Kinto Security Council on Layer 1 and can be executed without any delay.\nOn the Kinto Layer 2, critical permissions are mostly guarded by an AccessManager contract, and then passed down with configurable delays to both the Security Council and the 2/4 Kinto Multisig 2.\n\nThe Appchain designation of Kinto is mainly due to a modified L2 node, which queries a special censoring contract on L2 (called KintoAppRegistry) for a whitelist to filter transactions.\nThis makes the KintoAppRegistry contract a critical system contract and any change to its configuration equivalent to an upgrade of the Layer 2 system.\nThe KintoAppRegistry contract is also governed via the AccessManager by the Security Council or the Kinto Multisig 2 with a 12d delay.\n\nAnother critical contract on the Appchain is called KintoID. Permissioned actors with the 'KYC provider' role in the KintoID contract can 'sanction' (freeze) user smart wallets, preventing them from transacting.\nTo protect users from this role which is mostly held by EOAs, a sanction expires if not confirmed by the Security Council within 3d.\nAn expired sanction guarantees the user a 9d cooldown window during which they cannot be sanctioned again.\n\nThe canonical (enforced) smartwallet for users on Kinto can be upgraded via the KintoWalletFactory, using the same path via the AccessManager.\nAdditionally, each smart wallet must use a recoverer address custodied by Turnkey. This allows users to reset the wallet signers via their email in case they lose their passkey.\nIt also necessitates a recovery delay to prevent turnkey from maliciously using their recoverer permission. During this period of 12d, the user can cancel the recovery process with any transaction in their smart wallet.\n\nThe permissioned sanctions logic by KYC providers necessitates at least an 12d delay on all upgrades that aren't executed by the Security Council, allowing the user at least 7d to exit."
      },
      "warning": "Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted."
    }

• lachain +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-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": []
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the operator implements a TransactionFilterer, which is possible without delay."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
          }
        ]
      },
      "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": []
      },
      "stateDerivation": {
        "nodeSoftware": "The node software is open-source, and its source code can be found [here](https://github.com/matter-labs/zksync-era).\n    The main node software does not rely on Layer 1 (L1) to reconstruct the state, but you can use [this tool](https://github.com/eqlabs/zksync-state-reconstruct) for that purpose. Currently, there is no straightforward method to inject the state into the main node, but ZKsync is actively working on a solution for this.",
        "compressionScheme": "Bytecodes undergo compression before deployment on Layer 1 (L1). You can find additional information on this process [here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/advanced/11_compression.md).",
        "genesisState": "There have been neither genesis states nor regenesis.",
        "dataFormat": "Details on data format can be found [here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/advanced/09_pubdata.md)."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }

• lens +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-validium-vector",
      "dataAvailability": [
        {
          "name": "Data is posted to Avail",
          "description": "Transactions roots are posted onchain and the full data is posted on Avail.  The vector bridge is used to verify attestations from the Avail validator set that the data is indeed available.",
          "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": "AvailL1DAValidator - checkDA() function",
              "url": "https://etherscan.io/address/0x8f50d93B9955B285f787043B30B5F51D09bE0120#code#F1#L16"
            }
          ]
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the operator implements a TransactionFilterer, which is possible without delay."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
          }
        ]
      },
      "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": []
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }

• lighter +3 -1 Viewed

  • scalingTechnology +3 -1 Viewed

    {
      "dataAvailability": [
        {
          "name": "Data published onchain",
          "description": "Account delta data is published onchain as blobs. A prover migration (gnark/MIMC → plonky2/Poseidon2) at block 23,711,820 left pre-migration blobs undecodable, but Lighter published a full state snapshot at batch #166859 (blobs.zip) that closes the gap. L2BEAT reproduced the snapshot state root from blobs and verified the roll-forward to chain head, confirming the live state is reconstructable from L1.",
          "risks": [],
          "references": [
            {
              "title": "Lighter Prover v0.0.1 (first public release, Dec 2025)",
              "url": "https://github.com/elliottech/lighter-prover"
            },
            {
              "title": "StateRootUpdate event — gnark to plonky2 migration",
              "url": "https://etherscan.io/tx/0x6a50b2b00444914e5c53df2fb48404078a098f93fc3911e6fcbde1c7b6418225"
            },
            {
              "title": "Desert exit circuit + state snapshot (blobs.zip)",
              "url": "https://github.com/elliottech/lighter-prover/tree/main/desertexit"
            }
          ]
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exit",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is settled the funds become available for withdrawal on L1. ZK proofs are required to settle blocks. Finally the user submits an L1 transaction to claim the funds.",
          "risks": [],
          "references": []
        },
        {
          "name": "Escape hatch through ZK proofs",
          "description": "If the centralized operators fail to process forced transactions after the deadline, the system can be frozen (desert mode) and users are expected to exit by reconstructing the latest settled state and providing a ZK proof of balance. The desert exit circuit and a full state snapshot at batch #166859 are public, and the deployed DesertVerifier matches a rebuild from that circuit. L2BEAT reproduced the snapshot state root from L1 blobs and verified the roll-forward to chain head.",
          "risks": [],
          "references": [
            {
              "title": "Desert exit circuit + state snapshot",
              "url": "https://github.com/elliottech/lighter-prover/tree/main/desertexit"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can force their transactions on L1",
        "description": "If the centralized operators fail to include user transactions, users can force them themselves through L1. The possible transaction types that users can force are: deposits, withdrawals, order creation, order cancellation, and burning of pool shares. If the operators do not process forced transactions within 14d, the system can be frozen (desert mode) and users can exit using the latest settled state. All open positions are settled using the latest index price.",
        "risks": [],
        "references": []
      },
      "operator": {
        "name": "Centralized operators",
        "description": "Only the centralized operators can submit batches and verify them with a ZK proof, i.e. advance the state of the protocol.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "External oracles used for index prices",
          "description": "Lighter uses a combination of oracles to determine index prices, with Stork as the primary source. External signatures are currently not verified and the sequencer must be trusted to truthfully report data.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the oracle prices are manipulated."
            }
          ],
          "references": [
            {
              "title": "Lighter docs - Fair Price Marking",
              "url": "https://docs.lighter.xyz/perpetual-futures/fair-price-marking"
            }
          ]
        }
      ],
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid transactions to the previous state. This includes user transactions originating from L1 and L2, as well as internal transactions created by L2 operators. In the desert mode, valid proofs of exit must be generated. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "[This repo](https://github.com/elliottech/lighter-prover/tree/main) contains the circuits and prover code for both normal and desert operation mode of Lighter. It includes the logic to generate and verify proofs of valid state transition according to the Lighter [matching engine](https://github.com/elliottech/lighter-prover/blob/d0ff2304aea516b22f3a5223881006b6a9af1cc9/circuit/src/matching_engine.rs)."
          },
          {
            "title": "ZK Circuits",
            "description": "Lighter transition is proven with custom Plonky2 circuits, compiled into ZK Lighter Verifier and Desert Verifier. ZK Lighter verifier implements the perp DEX and spot trading logic and could be found in this [prover repo](https://github.com/elliottech/lighter-prover/tree/main/circuit/src). Desert verifier consists of circuits proving valid L2 -> L1 withdrawals in the desert mode. More details in [ZK Catalog](https://l2beat.com/zk-catalog/lighterprover#proof-system)."
          },
          {
            "title": "Verification Keys Generation",
            "description": "Lighter wraps its validity proof into a Plonk-based proof system which requires a trusted setup. The verification keys are hardcoded in the verifier contract on-chain. Lighter prover repo contains a [script](https://github.com/elliottech/lighter-prover/blob/main/build_circuits.sh) that regenerates circuits and verification keys.",
            "references": [
              {
                "title": "ZK Lighter verifier verification keys",
                "url": "https://etherscan.io/address/0xaa76aC5cC406037be638d483d8c1daF2AFDC1A68#code#F1#L54"
              },
              {
                "title": "Desert verifier verification keys",
                "url": "https://etherscan.io/address/0x2aDBd91742B64105a097bC37D20Ebbca9a496085#code#F1#L55"
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "Regular upgrades are initiated by the \"network governor\" and executed with a 21d delay. The \"security council\" is allowed to reduce the upgrade delay to zero in case of an emergency. The security council does not currently satisfy the Stage 1 requirements. The network governor also retains the ability to add or remove validators."
      "upgradesAndGovernance": {
        "content": "Regular upgrades are initiated by the \"network governor\" and executed with a 21d delay. The \"security council\" is allowed to reduce the upgrade delay to zero in case of an emergency. The security council does not currently satisfy the Stage 1 requirements. The network governor also retains the ability to add or remove validators."
      }
    }

• lumia +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-pessimistic",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Transaction data is kept off-chain. Bridge accounting is protected by pessimistic proofs while L2 state transitions are not proven on Ethereum.",
          "risks": [],
          "references": []
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "There is no general mechanism to force the sequencer to include the transaction.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            },
            {
              "category": "Funds can be stolen if",
              "text": "the operator manipulates the L2 state, which is not validated on Ethereum.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• nova +3 -1 Viewed

  • scalingTechnology +3 -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": [],
            "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": "\nAll 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."
      "upgradesAndGovernance": {
        "content": "\nAll 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."
      }
    }

• optimism +3 -1 Viewed

  • scalingTechnology +3 -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/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/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"
              }
            ]
          },
          {
            "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": "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."
      "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."
      }
    }

• penchain +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-pessimistic",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Transaction data is kept off-chain. Bridge accounting is protected by pessimistic proofs while L2 state transitions are not proven on Ethereum.",
          "risks": [],
          "references": []
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "There is no general mechanism to force the sequencer to include the transaction.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            },
            {
              "category": "Funds can be stolen if",
              "text": "the operator manipulates the L2 state, which is not validated on Ethereum.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• polygonzkevm +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-pessimistic",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "Transaction data is kept off-chain. Bridge accounting is protected by pessimistic proofs while L2 state transitions are not proven on Ethereum.",
          "risks": [],
          "references": []
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "There is no general mechanism to force the sequencer to include the transaction.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": []
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            },
            {
              "category": "Funds can be stolen if",
              "text": "the operator manipulates the L2 state, which is not validated on Ethereum.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• scroll +3 -1 Viewed

  • scalingTechnology +3 -1 Viewed

    {
      "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": "ScrollChain.sol - Etherscan source code commitBatches() function",
              "url": "https://etherscan.io/address/0x0a20703878E68E587c59204cc0EA86098B8c3bA7#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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "L1ETHGateway.sol - Etherscan source code, finalizeWithdrawETH function",
              "url": "https://etherscan.io/address/0x1fee6a6dC49095FB9C84D61aa4b8A07284b2A1d0#code"
            }
          ]
        }
      ],
      "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. The enforced liveness mechanism is activated if either an L1 message has not been finalized for more than 7d or a batch has not been finalized for more than 7d. When activated, transactions that were directly posted to the smart contract can be forcefully included by anyone on the host chain, which finalizes their ordering.",
        "risks": [],
        "references": [
          {
            "title": "EnforcedTxGateway.sol - Etherscan source code",
            "url": "https://etherscan.io/address/0x7e87c75BBe7991bbCEBd2C7a56f4cFC923BDDBcc#code"
          },
          {
            "title": "L1MessageQueueV2 - Etherscan proxy contract",
            "url": "https://etherscan.io/address/0x39C36c9026ac18104839A50c61a4507ea5052ECa"
          }
        ]
      },
      "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": "ScrollChain.sol - Etherscan source code, finalizeBundlePostEuclidV2() function modifier",
            "url": "https://etherscan.io/address/0x0a20703878E68E587c59204cc0EA86098B8c3bA7#code"
          }
        ]
      },
      "stateDerivation": {
        "nodeSoftware": "The node software to reconstruct the state is available [here](https://github.com/scroll-tech/go-ethereum). Note that it uses the L2 p2p network to fetch blocks, and not the L1 network. The consistency with L1 data can be checked by running the [scroll-geth node](https://github.com/scroll-tech/go-ethereum) with the `--rollup.verify` flag.",
        "compressionScheme": "Data batches are compressed using the [zstd](https://github.com/facebook/zstd) algorithm.",
        "genesisState": "The genesis file can be found [here](https://scrollzkp.notion.site/genesis-json-f89ca24b123f462f98c8844d17bdbb74), which contains two prefunded addresses and five predeployed contracts.",
        "dataFormat": "Blocks are grouped into chunks, chunks are grouped into batches, and batches are grouped into bundles. Chunk encoding format can be found [here](https://github.com/scroll-tech/scroll-contracts/blob/main/src/libraries/codec/ChunkCodecV0.sol#L5), and batch encoding format can be found [here](https://github.com/scroll-tech/da-codec/blob/main/encoding/codecv7_types.go#L20)."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "The prover code can be found [here](https://github.com/scroll-tech/zkvm-prover/tree/master/crates/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "Scroll circuits are [OpenVM](https://book.openvm.dev/)-based Guest Programs that use the OpenVM prover. The source code of the base circuits can be found [here](https://github.com/scroll-tech/zkvm-prover/tree/master/crates/circuits)."
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against Ethereum verifier contract using [this guide](https://github.com/scroll-tech/openvm/blob/66a8134a515c9f699d572e7f681311a04df3aef8/book/src/advanced-usage/sdk.md?plain=1#L99). The system requires a trusted setup."
          },
          {
            "title": "Validity proofs",
            "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
            "risks": [],
            "references": [
              {
                "title": "ScrollChain.sol - Etherscan source code, verifyAggregateProof() and verifyBundleProof() calls",
                "url": "https://etherscan.io/address/0x0a20703878E68E587c59204cc0EA86098B8c3bA7#code"
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "All core contracts in the Scroll protocol are upgradable by the `ProxyAdmin`, which is controlled by the Security Council through the `ScrollOwner` contract. The ScrollOwner is a central governance contract controlled by four distinct Timelocks: two governed by the Security Council multisig and two by the Scroll team multisigs. Each multisig can initiate specific types of changes with differing delay guarantees. The team has authority to revert unfinalized batches and add or remove sequencers and provers while sequencing is in permissioned mode. As the ScrollOwner admin, the Security Council can revert the team actions by revoking the team roles in the ScrollOwner contract (through the `TimelockSCSlow`) and upgrading the affected contracts. The Security Council can change parameters that affect L1->L2 messaging and the activation of permissionless sequencing (i.e., enforcedBatchMode), such as by calling the `updateMessageQueueParameters` and `updateEnforcedBatchParameters` functions or by pausing the `EnforcedTXGateway`. Emergency pause of core contracts is managed through the `PauseController`, which allows the team to pause batch commitment and finalization in permissioned mode, as well as L1->L2 messaging. Each pause is subject to a cooldown period of 1mo execution delay, during which the Security Council minority can unpause, while the Security Council majority is authorized to update and reset the cooldown period. SCR token holders perform onchain voting on governance proposals through the `AgoraGovernor` contract on L2. However, onchain governance proposals do not contain transaction payloads, so onchain voting only acts as an onchain temperature check. The Security Council is in charge of executing upgrades."
      "upgradesAndGovernance": {
        "content": "All core contracts in the Scroll protocol are upgradable by the `ProxyAdmin`, which is controlled by the Security Council through the `ScrollOwner` contract. The ScrollOwner is a central governance contract controlled by four distinct Timelocks: two governed by the Security Council multisig and two by the Scroll team multisigs. Each multisig can initiate specific types of changes with differing delay guarantees. The team has authority to revert unfinalized batches and add or remove sequencers and provers while sequencing is in permissioned mode. As the ScrollOwner admin, the Security Council can revert the team actions by revoking the team roles in the ScrollOwner contract (through the `TimelockSCSlow`) and upgrading the affected contracts. The Security Council can change parameters that affect L1->L2 messaging and the activation of permissionless sequencing (i.e., enforcedBatchMode), such as by calling the `updateMessageQueueParameters` and `updateEnforcedBatchParameters` functions or by pausing the `EnforcedTXGateway`. Emergency pause of core contracts is managed through the `PauseController`, which allows the team to pause batch commitment and finalization in permissioned mode, as well as L1->L2 messaging. Each pause is subject to a cooldown period of 1mo execution delay, during which the Security Council minority can unpause, while the Security Council majority is authorized to update and reset the cooldown period. SCR token holders perform onchain voting on governance proposals through the `AgoraGovernor` contract on L2. However, onchain governance proposals do not contain transaction payloads, so onchain voting only acts as an onchain temperature check. The Security Council is in charge of executing upgrades."
      }
    }

• silicon +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-validium",
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "There is no general mechanism to force the sequencer to include the transaction.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, forceBatchAddress address",
            "url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "Only a trusted sequencer is allowed to submit transaction batches.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          },
          {
            "category": "Funds can be frozen if",
            "text": "the sequencer refuses to include an exit transaction.",
            "isCritical": true
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, onlyTrustedSequencer modifier",
            "url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation.",
        "compressionScheme": "No compression scheme is used.",
        "genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
        "dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/tools/zkevm/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
          },
          {
            "title": "ZK Circuits",
            "description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
          },
          {
            "title": "Pessimistic Proofs",
            "description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
          },
          {
            "title": "Validity proofs",
            "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
            "risks": [],
            "references": [
              {
                "title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
                "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• sophon +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-validium-vector",
      "dataAvailability": [
        {
          "name": "Data is posted to Avail",
          "description": "Transactions roots are posted onchain and the full data is posted on Avail.  The vector bridge is used to verify attestations from the Avail validator set that the data is indeed available.",
          "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": "AvailL1DAValidator - checkDA() function",
              "url": "https://etherscan.io/address/0x8f50d93B9955B285f787043B30B5F51D09bE0120#code#F1#L16"
            }
          ]
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can't force all transactions",
        "description": "If a user is censored by the L2 Sequencer, they cannot by default force their transaction via the L1 queue. An active TransactionFilterer contract which allows only whitelisted accounts to enqueue, prevents it. Even if a user was specifically whitelisted, there is no mechanism that forces the L2 Sequencer to include            transactions from the queue in an L2 block, as they have the choice to process the queue in order or not at all. The L2AssetRouter contract is currently whitelisted as a target in the TransactionFilterer which allows users to queue withdrawals that use the canonical bridge from L1.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the Operator does not specifically whitelist them in the TransactionFilterer."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/rollup/l1_l2_communication#priority-operations-1"
          },
          {
            "title": "Mailbox facet",
            "url": "https://etherscan.io/address/0x1e34aB39a9682149165ddeCc0583d238A5448B45#code#F1#L405"
          },
          {
            "title": "TransactionFilterer",
            "url": "https://etherscan.io/address/0x9D06B34adc3026eF876e4DABb859C424DbDA3063#code#F1#L34"
          }
        ]
      },
      "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": []
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }

• starknet +3 -1 Viewed

  • scalingTechnology +3 -1 Viewed

    {
      "dataAvailability": [
        {
          "name": "All data required to reconstruct rollup state is published on chain",
          "description": "State diffs are publish onchain as blob or calldata on every state update. The state diffs contain information on every contact whose storage was updated, and additional information on contract deployments. From diffs full system state can be recovered. Contracts' code is not published on L1, but can be trustlessly verified if available elsewhere.",
          "risks": [],
          "references": [
            {
              "title": "On-Chain Data - Starknet documentation",
              "url": "https://docs.starknet.io/architecture/data-availability/"
            }
          ]
        }
      ],
      "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. ZK proofs are required to settle blocks. Note that the message request can be censored by the Sequencer.",
          "risks": [
            {
              "category": "Funds can be frozen if",
              "text": "the operator censors withdrawal transaction."
            }
          ],
          "references": [
            {
              "title": "Withdrawing is based on l2 to l1 messages - Starknet documentation",
              "url": "https://book.cairo-lang.org/ch16-04-L1-L2-messaging.html#sending-messages-from-starknet-to-ethereum"
            }
          ]
        },
        {
          "name": "Emergency exit",
          "risks": [],
          "description": "There is no generic escape hatch mechanism as Starknet cannot be forced by users into a frozen state. Note that a freezing mechanism on L2, to be secure, requires anti-censorship protection.",
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "There is no general mechanism to force the sequencer to include the transaction.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": [
          {
            "title": "Censorship resistance of Starknet - Forum Discussion",
            "url": "https://community.starknet.io/t/censorship-resistance/196"
          }
        ]
      },
      "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. Typically, the Operator is the hot wallet of the Starknet service submitting state updates for which proofs have been already submitted and verified.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ],
        "references": []
      },
      "stateDerivation": {
        "nodeSoftware": "The [Juno](https://github.com/NethermindEth/juno) node software can be used to reconstruct the L2 state entirely from L1. The feature has not been released yet, but can be found in this [PR](https://github.com/NethermindEth/juno/pull/1335).",
        "compressionScheme": "Starknet uses [stateful compression since v0.13.4](https://docs.starknet.io/architecture/data-availability/#v0_13_4).",
        "genesisState": "There is no non-empty genesis state.",
        "dataFormat": "The data format has been updated with different versions, and the full specification can be found [here](https://docs.starknet.io/architecture/data-availability/)."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Proven Program",
            "description": "The source code of the Starknet OS can be found [here](https://github.com/keep-starknet-strange/snos). The source code of the bootloader can be found [here](https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/cairo/bootloaders/bootloader/bootloader.cairo).",
            "risks": []
          },
          {
            "title": "Validity proofs",
            "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
            "risks": [],
            "references": [
              {
                "title": "What is Starknet",
                "url": "https://starkware.co/starknet/"
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "\nThe Starknet zk Rollup shares its SHARP verifier with other StarkEx and SN Stack Layer 2s. Governance of the main Starknet rollup contract and its core bridge escrows (ETHBridge, STRKBridge) is currently split between the 9/12 Security Council with instant upgrade capability and the 2/4 Starkware Multisig 2 who can upgrade with a 8d delay. The former Multisig also governs most other bridge escrows with instant upgradeability. The shared SHARP verifier used for state validation can be changed by the 2/4 SHARP Multisig with and a 8d delay, affecting all rollups like Starknet that are sharing it. \n\nThe Operator role in the Starknet contract is permissioned to update the state of the Starknet rollup by supplying valid (zk) state transition proofs. Since this role is not permissionless, Starknet implements a StarknetSCMinorityMultisig with the Operator role, which allows a 3/12 minority of the StarknetSecurityCouncil to enforce censorship resistance by including transactions that are not included by regular Operators.\n\nAll bridge escrows allow enabling a withdrawal throttle of 5% of the locked funds per 24h period. Enabling it is permissioned to a Multisig while disabling it in the core bridge escrows (STRKBridge, ETHBridge) can be done by a 3/12 minority of the Security Council.\n"
      "upgradesAndGovernance": {
        "content": "\nThe Starknet zk Rollup shares its SHARP verifier with other StarkEx and SN Stack Layer 2s. Governance of the main Starknet rollup contract and its core bridge escrows (ETHBridge, STRKBridge) is currently split between the 9/12 Security Council with instant upgrade capability and the 2/4 Starkware Multisig 2 who can upgrade with a 8d delay. The former Multisig also governs most other bridge escrows with instant upgradeability. The shared SHARP verifier used for state validation can be changed by the 2/4 SHARP Multisig with and a 8d delay, affecting all rollups like Starknet that are sharing it. \n\nThe Operator role in the Starknet contract is permissioned to update the state of the Starknet rollup by supplying valid (zk) state transition proofs. Since this role is not permissionless, Starknet implements a StarknetSCMinorityMultisig with the Operator role, which allows a 3/12 minority of the StarknetSecurityCouncil to enforce censorship resistance by including transactions that are not included by regular Operators.\n\nAll bridge escrows allow enabling a withdrawal throttle of 5% of the locked funds per 24h period. Enabling it is permissioned to a Multisig while disabling it in the core bridge escrows (STRKBridge, ETHBridge) can be done by a 3/12 minority of the Security Council.\n"
      }
    }

• sxt +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-validium",
      "dataAvailability": [
        {
          "name": "Data is posted to Avail",
          "description": "Transactions roots are posted onchain and the full data is posted on Avail.  The vector bridge is used to verify attestations from the Avail validator set that the data is indeed available.",
          "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": "AvailL1DAValidator - checkDA() function",
              "url": "https://etherscan.io/address/0x8f50d93B9955B285f787043B30B5F51D09bE0120#code#F1#L16"
            }
          ]
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the operator implements a TransactionFilterer, which is possible without delay."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
          }
        ]
      },
      "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": []
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }

• taiko +3 -1 Viewed

  • scalingTechnology +3 -1 Viewed

    {
      "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 blobs. This ensures that it will be available for enough time.",
          "references": [],
          "risks": []
        }
      ],
      "exitMechanisms": [
        {
          "name": "Regular exit",
          "description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "Users can submit a blob reference containing a standalone transaction by calling the `saveForcedInclusion()` function on the `MainnetInbox` contract.\n        Once any forced inclusion has been queued for 9m 36s, whitelisted proposers cannot submit new proposals unless they process all due forced inclusions.\n        If the oldest queued forced inclusion is still ignored for 1d 1h, proposing becomes permissionless and anyone can include it.",
        "references": [
          {
            "title": "MainnetInbox.sol - Etherscan source code, saveForcedInclusion function",
            "url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
          },
          {
            "title": "MainnetInbox.sol - Etherscan source code, propose function",
            "url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
          }
        ],
        "risks": []
      },
      "operator": {
        "name": "The system uses whitelist-based sequencing and proving",
        "description": "The system uses a whitelist-based sequencing mechanism to allow for fast preconfirmations on the L2. On the L1, whitelisted preconfirmers can propose Taiko L2 data to the MainnetInbox contract.\n        The whitelist is managed by the `PreconfWhitelist` contract, which currently has 3 active operators registered.\n        Forced inclusions become mandatory after 9m 36s and proposing becomes permissionless after 1d 1h if the queue is still ignored.\n        Proving is controlled separately by `ProverWhitelist`, which currently has 1 whitelisted prover.\n        Non-whitelisted actors must wait 5d after an unproven proposal before the whitelist is dropped. MainnetInbox currently sets minBond=0 and livenessBond=0.\n        Currently, proving a proposal requires SGX (Geth), plus either SGX (Reth), SP1, or RISC0.",
        "references": [
          {
            "title": "MainnetInbox.sol - Etherscan source code, propose function",
            "url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
          },
          {
            "title": "MainnetInbox.sol - Etherscan source code, prove function",
            "url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
          },
          {
            "title": "PreconfWhitelist.sol - Etherscan source code",
            "url": "https://etherscan.io/address/0xDBae46E35C18719E6c78aaBF9c8869c4eC84c149#code"
          },
          {
            "title": "ProverWhitelist.sol - Etherscan source code",
            "url": "https://etherscan.io/address/0xEa798547d97e345395dA071a0D7ED8144CD612Ae#code"
          }
        ],
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          }
        ]
      },
      "stateValidation": {
        "categories": [
          {
            "title": "Validity proofs",
            "description": "Taiko uses a multi-proof system to validate state transitions. The system requires two proofs among four available verifiers: SGX (Geth), SGX (Reth), SP1, and RISC0. This means that a proposal range can be proven without providing a ZK proof if SGX (Geth) and SGX (Reth) are used together. New proposals target a proof submission cadence of 4h. Proving is currently centralized behind ProverWhitelist with 1 whitelisted prover. Non-whitelisted actors must wait 5d before the whitelist is dropped, and MainnetInbox currently sets minBond=0 and livenessBond=0. The multi-proof system allows detecting bugs in the verifiers if they produce different results for the same proposal range. If such a bug is detected, the system gets automatically paused.",
            "references": [
              {
                "title": "MainnetInbox.sol - Etherscan source code, getConfig function",
                "url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
              },
              {
                "title": "MainnetInbox.sol - Etherscan source code, prove function",
                "url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
              },
              {
                "title": "ProverWhitelist.sol - Etherscan source code",
                "url": "https://etherscan.io/address/0xEa798547d97e345395dA071a0D7ED8144CD612Ae#code"
              }
            ],
            "risks": [
              {
                "category": "Funds can be stolen if",
                "text": "a malicious block is proven by compromised SGX instances."
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "\nTaiko Alethia has a governance structure relying primarily on a 7/9 Security Council, checked by a token DAO that is limited to veto permissions. The closed operator whitelists are managed by the 4/6 Taiko Multisig and related EOAs. Governance proposals (both paths) hold all important upgrade and config permissions in the system.\n# Standard proposals\nA threshold of 5 approving Security Council members is required to create a Standard proposal. It is delayed while being publicly auditable by 7d in the OptimisticTokenVotingPlugin contract and can be vetoed by 10% of votable TAIKO tokens during that time. If not vetoed, the standard proposal passes and can be executed.\n# Emergency proposals\nEmergency proposals are encrypted at proposal time and can only be read by Security Council members. If approved by 7 Security Council members, they can be immediately decrypted and executed.\n\n# Proof system and operators\nThe proof system currently does not require zk proofs to validate state transitions and state can be finalized with SGX proofs only. The optional zk verifier contracts can be upgraded by Multisigs. Operator roles (sequencer, proposer) are closed and the whitelist is managed by the Taiko Multisig and related EOAs.\n"
      "upgradesAndGovernance": {
        "content": "\nTaiko Alethia has a governance structure relying primarily on a 7/9 Security Council, checked by a token DAO that is limited to veto permissions. The closed operator whitelists are managed by the 4/6 Taiko Multisig and related EOAs. Governance proposals (both paths) hold all important upgrade and config permissions in the system.\n# Standard proposals\nA threshold of 5 approving Security Council members is required to create a Standard proposal. It is delayed while being publicly auditable by 7d in the OptimisticTokenVotingPlugin contract and can be vetoed by 10% of votable TAIKO tokens during that time. If not vetoed, the standard proposal passes and can be executed.\n# Emergency proposals\nEmergency proposals are encrypted at proposal time and can only be read by Security Council members. If approved by 7 Security Council members, they can be immediately decrypted and executed.\n\n# Proof system and operators\nThe proof system currently does not require zk proofs to validate state transitions and state can be finalized with SGX proofs only. The optional zk verifier contracts can be upgraded by Multisigs. Operator roles (sequencer, proposer) are closed and the whitelist is managed by the Taiko Multisig and related EOAs.\n"
      }
    }

• ternoa +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-validium",
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "There is no general mechanism to force the sequencer to include the transaction.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, forceBatchAddress address",
            "url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "Only a trusted sequencer is allowed to submit transaction batches.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          },
          {
            "category": "Funds can be frozen if",
            "text": "the sequencer refuses to include an exit transaction.",
            "isCritical": true
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, onlyTrustedSequencer modifier",
            "url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation.",
        "compressionScheme": "No compression scheme is used.",
        "genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
        "dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/tools/zkevm/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
          },
          {
            "title": "ZK Circuits",
            "description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
          },
          {
            "title": "Pessimistic Proofs",
            "description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
          },
          {
            "title": "Validity proofs",
            "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
            "risks": [],
            "references": [
              {
                "title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
                "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• treasure +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-validium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "The transaction data is not recorded on the Ethereum main chain. Transaction data is stored off-chain and only the hashes are posted onchain by the centralized Sequencer.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "ExecutorFacet - _commitOneBatch() function",
              "url": "https://etherscan.io/address/0x53d0b421BB3e522632ABEB06BB2c4eB15eaD9800#code#F1#L46"
            }
          ]
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the operator implements a TransactionFilterer, which is possible without delay."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
          }
        ]
      },
      "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": []
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }

• wirex +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-validium",
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "There is no general mechanism to force the sequencer to include the transaction.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, forceBatchAddress address",
            "url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "Only a trusted sequencer is allowed to submit transaction batches.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          },
          {
            "category": "Funds can be frozen if",
            "text": "the sequencer refuses to include an exit transaction.",
            "isCritical": true
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, onlyTrustedSequencer modifier",
            "url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation.",
        "compressionScheme": "No compression scheme is used.",
        "genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
        "dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/tools/zkevm/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
          },
          {
            "title": "ZK Circuits",
            "description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
          },
          {
            "title": "Pessimistic Proofs",
            "description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
          },
          {
            "title": "Validity proofs",
            "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
            "risks": [],
            "references": [
              {
                "title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
                "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• witness +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-validium",
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "forceTransactions": {
        "name": "Users can't force any transaction",
        "description": "There is no general mechanism to force the sequencer to include the transaction.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, forceBatchAddress address",
            "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
          }
        ]
      },
      "operator": {
        "name": "The system has a centralized sequencer",
        "description": "Only a trusted sequencer is allowed to submit transaction batches.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          },
          {
            "category": "Funds can be frozen if",
            "text": "the sequencer refuses to include an exit transaction.",
            "isCritical": true
          }
        ],
        "references": [
          {
            "title": "Validium.sol - source code, onlyTrustedSequencer modifier",
            "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
          }
        ]
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "stateDerivation": {
        "nodeSoftware": "Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation.",
        "compressionScheme": "No compression scheme is used.",
        "genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
        "dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/tools/zkevm/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
          },
          {
            "title": "ZK Circuits",
            "description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
          },
          {
            "title": "Pessimistic Proofs",
            "description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
          },
          {
            "title": "Validity proofs",
            "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
            "risks": [],
            "references": [
              {
                "title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
                "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
              }
            ]
          }
        ]
      },
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• wonder +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-validium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "The transaction data is not recorded on the Ethereum main chain. Transaction data is stored off-chain and only the hashes are posted onchain by the centralized Sequencer.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "ExecutorFacet - _commitOneBatch() function",
              "url": "https://etherscan.io/address/0x2f116b9033d88Bb3Cf64C371AE5458fbA22BA39A#code#F1#L50"
            }
          ]
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the operator implements a TransactionFilterer, which is possible without delay."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
          }
        ]
      },
      "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": []
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }

• xlayer +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "agglayer-opstack_closed",
      "dataAvailability": [
        {
          "name": "Data is posted on Ethereum",
          "description": "Transaction data is posted to Ethereum L1 as compressed calldata or blobs through the OP Stack batch inbox.",
          "risks": [],
          "references": []
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "AgglayerBridge.sol - source code, claimAsset function",
              "url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
            }
          ]
        }
      ],
      "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": []
      },
      "otherConsiderations": [
        {
          "name": "Shared bridge and Pessimistic Proofs",
          "description": "Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them 'Pessimistic Proofs') are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVM by Succinct, even projects without a full proof system on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
            },
            {
              "category": "Funds can be stolen if",
              "text": "the operator manipulates the L2 state, which is not validated on Ethereum.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "Pessimistic Proof - Polygon Knowledge Layer",
              "url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
            },
            {
              "title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
              "url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
            }
          ]
        }
      ],
      "upgradesAndGovernance": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "upgradesAndGovernanceImage": "agglayer"
      "upgradesAndGovernance": {
        "content": "\nThe regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.\n\nThe PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.\n\nFurthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
        "image": "agglayer"
      }
    }

• zeronetwork +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-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": []
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the operator implements a TransactionFilterer, which is possible without delay."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
          }
        ]
      },
      "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": []
      },
      "stateDerivation": {
        "nodeSoftware": "The node software is open-source, and its source code can be found [here](https://github.com/matter-labs/zksync-era).\n    The main node software does not rely on Layer 1 (L1) to reconstruct the state, but you can use [this tool](https://github.com/eqlabs/zksync-state-reconstruct) for that purpose. Currently, there is no straightforward method to inject the state into the main node, but ZKsync is actively working on a solution for this.",
        "compressionScheme": "Bytecodes undergo compression before deployment on Layer 1 (L1). You can find additional information on this process [here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/advanced/11_compression.md).",
        "genesisState": "There have been neither genesis states nor regenesis.",
        "dataFormat": "Details on data format can be found [here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/advanced/09_pubdata.md)."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }

• zkcandy +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-validium",
      "dataAvailability": [
        {
          "name": "Data is not stored on chain",
          "description": "The transaction data is not recorded on the Ethereum main chain. Transaction data is stored off-chain and only the hashes are posted onchain by the centralized Sequencer.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "ExecutorFacet - _commitOneBatch() function",
              "url": "https://etherscan.io/address/0x0597CaA8A823A699d7CD9E62B5E5d4153FF82691#code#F1#L60"
            }
          ]
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the operator implements a TransactionFilterer, which is possible without delay."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
          }
        ]
      },
      "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": []
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }

• zksync2 +4 -2 Viewed

  • scalingTechnology +4 -2 Viewed

    {
      "architectureImage": "zkstack-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": []
        }
      ],
      "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. ZK proofs are required to settle blocks.",
          "risks": [],
          "references": [
            {
              "title": "Withdrawing funds - ZKsync documentation",
              "url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
            }
          ]
        },
        {
          "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 from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
          "risks": [],
          "references": []
        }
      ],
      "forceTransactions": {
        "name": "Users can force any transaction via L1",
        "description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
        "risks": [
          {
            "category": "Users can be censored if",
            "text": "the operator refuses to include their transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the operator implements a TransactionFilterer, which is possible without delay."
          }
        ],
        "references": [
          {
            "title": "L1 - L2 interoperability - Developer's documentation",
            "url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
          }
        ]
      },
      "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.\n\nBatch execution is initiated by permissioned executor EOAs, but each batch also requires approval from the sufficient number of EraMultisigValidator members before it can be executed on L1.",
        "risks": [
          {
            "category": "MEV can be extracted if",
            "text": "the operator exploits their centralized position and frontruns user transactions."
          },
          {
            "category": "Users can be censored if",
            "text": "the validator multisig does not approve batch execution."
          }
        ],
        "references": [
          {
            "title": "EraMultisigValidator - Etherscan proxy contract",
            "url": "https://etherscan.io/address/0xdC26B08F0335b68721F64001C38b05D0BC9B539d"
          }
        ]
      },
      "stateDerivation": {
        "nodeSoftware": "The node software is open-source, and its source code can be found [here](https://github.com/matter-labs/zksync-era).\n    The main node software does not rely on Layer 1 (L1) to reconstruct the state, but you can use [this tool](https://github.com/eqlabs/zksync-state-reconstruct) for that purpose. Currently, there is no straightforward method to inject the state into the main node, but ZKsync is actively working on a solution for this.",
        "compressionScheme": "Bytecodes undergo compression before deployment on Layer 1 (L1). You can find additional information on this process [here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/advanced/11_compression.md).",
        "genesisState": "There have been neither genesis states nor regenesis.",
        "dataFormat": "Details on data format can be found [here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/advanced/09_pubdata.md)."
      },
      "stateValidation": {
        "description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
        "categories": [
          {
            "title": "Prover Architecture",
            "description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
          },
          {
            "title": "ZK Circuits",
            "description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
            "risks": [
              {
                "category": "Funds can be lost if",
                "text": "the proof system is implemented incorrectly."
              }
            ]
          },
          {
            "title": "Verification Keys Generation",
            "description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
          }
        ]
      },
      "upgradesAndGovernance": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
      "upgradesAndGovernanceImage": "zkstack"
      "upgradesAndGovernance": {
        "content": "\nThere are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
        "image": "zkstack"
      }
    }