Diff between 83ea2101 (main) and 3982407f (PR)

• astarzkevm +12 -17 Viewed

  • scalingRisks +1 -1 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "Validity proofs (ST, SN)",
          "description": "STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.",
          "sentiment": "good",
          "orderHint": null,
          "executionDelay": 0,
          "secondLine": "No execution delay"
        },
        "dataAvailability": {
          "value": "External (DAC)",
          "description": "Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC) with a threshold of 3/5 that is tasked with protecting and supplying the data.",
          "sentiment": "bad",
          "orderHint": 0.6
        },
        "exitWindow": {
          "value": "None",
          "description": "Even though there is a 3d Timelock for upgrades, forced transactions are disabled.",
          "description": "Even though there is a 3d Timelock for upgrades, there are no forced transactions and thus no way to exit during operator censorship or downtime.",
          "sentiment": "bad",
          "orderHint": -1,
          "warning": {
            "value": "The Security Council can remove the delay on upgrades.",
            "sentiment": "bad"
          }
        },
        "sequencerFailure": {
          "value": "No mechanism",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
          "sentiment": "bad"
        },
        "proposerFailure": {
          "value": "Cannot withdraw",
          "description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
          "sentiment": "bad",
          "orderHint": null
        }
      }
    }

  • scalingTechnology +10 -10 Viewed

    {
      "architectureImage": "polygon-cdk-validium",
      "architectureImage": "agglayer-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 Sequencer, after being signed by the DAC members.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "PolygonValidiumStorageMigration.sol - Etherscan source code, sequenceBatchesValidium function",
              "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code#F1#L126"
              "title": "Validium.sol - Etherscan source code, sequenceBatchesValidium function",
              "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code#F1#L91"
            }
          ]
        }
      ],
      "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": "The mechanism for allowing users to submit their own transactions is currently disabled.",
        "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. A mechanism for users to submit their own batches is currently disabled.",
        "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-sovereign'). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum 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.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` 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 AstarValidium contract."
        "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/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 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. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "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 Validium 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": "polygoncdk"
    }

  • livenessConfig +1 -6 Viewed

    {
      "duplicateData": {
        "from": "stateUpdates",
        "to": "proofSubmissions"
      }
    }
    null

• gpt +8 -13 Viewed

  • scalingRisks +1 -1 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "Validity proofs (ST, SN)",
          "description": "STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.",
          "sentiment": "good",
          "orderHint": null,
          "executionDelay": 0,
          "secondLine": "No execution delay"
        },
        "dataAvailability": {
          "value": "External (DAC)",
          "description": "Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC) with a threshold of 1/2 that is tasked with protecting and supplying the data.",
          "sentiment": "bad",
          "orderHint": 0.5
        },
        "exitWindow": {
          "value": "None",
          "description": "Even though there is a 3d Timelock for upgrades, forced transactions are disabled.",
          "description": "Even though there is a 3d Timelock for upgrades, there are no forced transactions and thus no way to exit during operator censorship or downtime.",
          "sentiment": "bad",
          "orderHint": -1,
          "warning": {
            "value": "The Security Council can remove the delay on upgrades.",
            "sentiment": "bad"
          }
        },
        "sequencerFailure": {
          "value": "No mechanism",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
          "sentiment": "bad"
        },
        "proposerFailure": {
          "value": "Cannot withdraw",
          "description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
          "sentiment": "bad",
          "orderHint": null
        }
      }
    }

  • scalingTechnology +6 -6 Viewed

    {
      "architectureImage": "polygon-cdk-validium",
      "architectureImage": "agglayer-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 Sequencer, after being signed by the DAC members.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "PolygonValidiumStorageMigration.sol - Etherscan source code, sequenceBatchesValidium function",
              "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code#F1#L126"
              "title": "Validium.sol - Etherscan source code, sequenceBatchesValidium function",
              "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code#F1#L91"
            }
          ]
        }
      ],
      "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": "The mechanism for allowing users to submit their own transactions is currently disabled.",
        "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. A mechanism for users to submit their own batches is currently disabled.",
        "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-sovereign'). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum 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.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 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. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "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 Validium 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": "polygoncdk"
    }

  • livenessConfig +1 -6 Viewed

    {
      "duplicateData": {
        "from": "stateUpdates",
        "to": "proofSubmissions"
      }
    }
    null

• haust +39 -4 Viewed

  • scalingRisks +1 -1 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "None",
          "description": "Currently the system permits invalid state roots. 'Pessimistic' proofs only validate the bridge accounting.",
          "sentiment": "bad",
          "orderHint": null
        },
        "dataAvailability": {
          "value": "External",
          "description": "Proof construction and state derivation rely fully on data that is NOT published onchain.",
          "sentiment": "bad"
        },
        "exitWindow": {
          "value": "None",
          "description": "There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.",
          "sentiment": "bad",
          "orderHint": 0
        },
        "sequencerFailure": {
          "value": "No mechanism",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring.",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
          "sentiment": "bad"
        },
        "proposerFailure": {
          "value": "Cannot withdraw",
          "description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
          "sentiment": "bad",
          "orderHint": null
        }
      }
    }

  • scalingTechnology +38 -3 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-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.",
          "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'). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum 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."
            },
            {
              "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/learn/agglayer/pessimistic_proof"
              "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": "polygoncdk"
    }

• lumia +44 -6 Viewed

  • scalingInfo +5 -2 Viewed

    {
      "capability": "universal",
      "daLayer": [
        "None"
      ],
      "hostChain": {
        "id": "ethereum",
        "slug": "ethereum",
        "name": "Ethereum"
      },
      "infrastructure": "Agglayer",
      "layer": "layer2",
      "purposes": [
        "Universal",
        "Restaking",
        "RWA",
        "Universal"
        "RWA"
      ],
      "reasonsForBeingOther": [
        {
          "label": "No DA bridge",
          "shortDescription": "There is no data availability bridge",
          "description": "Projects without a data availability bridge fully rely on single entities (the sequencer) to honestly rely available data roots on Ethereum. A malicious sequencer can collude with the proposer to finalize an unavailable state, which can cause loss of funds."
        },
        {
          "label": "No proofs",
          "shortDescription": "The proof system isn't fully functional",
          "description": "Projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds."
        }
      ],
      "stacks": [
        "Agglayer CDK"
      ],
      "stage": "Not applicable",
      "type": "Other",
      "vm": []
    }

  • scalingRisks +1 -1 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "None",
          "description": "Currently the system permits invalid state roots. 'Pessimistic' proofs only validate the bridge accounting.",
          "sentiment": "bad",
          "orderHint": null
        },
        "dataAvailability": {
          "value": "External",
          "description": "Proof construction and state derivation rely fully on data that is NOT published onchain.",
          "sentiment": "bad"
        },
        "exitWindow": {
          "value": "None",
          "description": "There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.",
          "sentiment": "bad",
          "orderHint": 0
        },
        "sequencerFailure": {
          "value": "No mechanism",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring.",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
          "sentiment": "bad"
        },
        "proposerFailure": {
          "value": "Cannot withdraw",
          "description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
          "sentiment": "bad",
          "orderHint": null
        }
      }
    }

  • scalingTechnology +38 -3 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-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.",
          "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'). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum 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."
            },
            {
              "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/learn/agglayer/pessimistic_proof"
              "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": "polygoncdk"
    }

• penchain +19 -16 Viewed

  • milestones +9 -1 Viewed

    []
    [
      {
        "title": "Mainnet Launch",
        "url": "https://x.com/PentagonChain/status/1942909180932718920",
        "date": "2025-07-09",
        "description": "Pentagon Chain mainnet is live.",
        "type": "general"
      }
    ]

  • scalingRisks +1 -1 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "Validity proofs (ST, SN)",
          "description": "STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.",
          "sentiment": "good",
          "orderHint": null,
          "executionDelay": 0,
          "secondLine": "No execution delay"
        },
        "dataAvailability": {
          "value": "External (DAC)",
          "description": "Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC) with a threshold of 1/1 that is tasked with protecting and supplying the data.",
          "sentiment": "bad",
          "orderHint": 1
        },
        "exitWindow": {
          "value": "None",
          "description": "Even though there is a 3d Timelock for upgrades, forced transactions are disabled.",
          "description": "Even though there is a 3d Timelock for upgrades, there are no forced transactions and thus no way to exit during operator censorship or downtime.",
          "sentiment": "bad",
          "orderHint": -1,
          "warning": {
            "value": "The Security Council can remove the delay on upgrades.",
            "sentiment": "bad"
          }
        },
        "sequencerFailure": {
          "value": "No mechanism",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
          "sentiment": "bad"
        },
        "proposerFailure": {
          "value": "Cannot withdraw",
          "description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
          "sentiment": "bad",
          "orderHint": null
        }
      }
    }

  • scalingTechnology +8 -8 Viewed

    {
      "architectureImage": "polygon-cdk-validium",
      "architectureImage": "agglayer-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 Sequencer, after being signed by the DAC members.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "PolygonValidiumEtrog.sol - Etherscan source code, sequenceBatchesValidium function",
              "url": "https://etherscan.io/address//0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code#F1#L91"
              "title": "Validium.sol - Etherscan source code, sequenceBatchesValidium function",
              "url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code#F1#L91"
            }
          ]
        }
      ],
      "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": "The mechanism for allowing users to submit their own transactions is currently disabled.",
        "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. A mechanism for users to submit their own batches is currently disabled.",
        "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-sovereign'). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum 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.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`](https://evm.storage/eth/19489007/0x5132a183e9f3cb7c848b0aac5ae0c4f0491b7ab2/_legacyBatchNumToStateRoot#map) variable of AgglayerManager, is available [here](https://github.com/0xPolygonHermez/zkevm-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
        "dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/transaction-batching/)."
        "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/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 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. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "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 Validium 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": "polygoncdk"
    }

  • livenessConfig +1 -6 Viewed

    {
      "duplicateData": {
        "from": "stateUpdates",
        "to": "proofSubmissions"
      }
    }
    null

• polygonzkevm +43 -5 Viewed

  • chainConfig +3 -0 Viewed

    {
      "apis": [
        {
          "type": "rpc",
          "url": "https://polygon-rpc.com/zkevm",
          "callsPerMinute": 500
        },
        {
          "type": "etherscan",
          "chainId": 1101
        },
        {
          "type": "blockscoutV2",
          "url": "https://zkevm.blockscout.com/api/v2"
        }
      ],
      "chainId": 1101,
      "coingeckoPlatform": "polygon-zkevm",
      "explorerUrl": "https://zkevm.polygonscan.com",
      "gasTokens": [
        "ETH"
      ],
      "multicallContracts": [
        {
          "address": "0xcA11bde05977b3631167028862bE2a173976CA11",
          "batchSize": 150,
          "sinceBlock": 57746,
          "version": "3"
        }
      ],
      "name": "polygonzkevm",
      "sinceTimestamp": 1679679015
    }

  • scalingRisks +1 -1 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "None",
          "description": "Currently the system permits invalid state roots. 'Pessimistic' proofs only validate the bridge accounting.",
          "sentiment": "bad",
          "orderHint": null
        },
        "dataAvailability": {
          "value": "External",
          "description": "Proof construction and state derivation rely fully on data that is NOT published onchain.",
          "sentiment": "bad"
        },
        "exitWindow": {
          "value": "None",
          "description": "There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.",
          "sentiment": "bad",
          "orderHint": 0
        },
        "sequencerFailure": {
          "value": "No mechanism",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring.",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
          "sentiment": "bad"
        },
        "proposerFailure": {
          "value": "Cannot withdraw",
          "description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
          "sentiment": "bad",
          "orderHint": null
        }
      }
    }

  • scalingTechnology +38 -3 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-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.",
          "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'). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum 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."
            },
            {
              "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/learn/agglayer/pessimistic_proof"
              "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": "polygoncdk"
    }

  • discoveryInfo +1 -1 Viewed

    {
      "baseTimestamp": 1764944434,
      "baseTimestamp": 1763987450,
      "contractsDiscoDriven": true,
      "hasDiscoUi": true,
      "isDiscoDriven": true,
      "permissionsDiscoDriven": true
    }

• silicon +9 -14 Viewed

  • scalingRisks +1 -1 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "Validity proofs (ST, SN)",
          "description": "STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.",
          "sentiment": "good",
          "orderHint": null,
          "executionDelay": 0,
          "secondLine": "No execution delay"
        },
        "dataAvailability": {
          "value": "External (DAC)",
          "description": "Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC) with a threshold of 2/3 that is tasked with protecting and supplying the data.",
          "sentiment": "bad",
          "orderHint": 0.6666666666666666
        },
        "exitWindow": {
          "value": "None",
          "description": "Even though there is a 3d Timelock for upgrades, forced transactions are disabled.",
          "description": "Even though there is a 3d Timelock for upgrades, there are no forced transactions and thus no way to exit during operator censorship or downtime.",
          "sentiment": "bad",
          "orderHint": -1,
          "warning": {
            "value": "The Security Council can remove the delay on upgrades.",
            "sentiment": "bad"
          }
        },
        "sequencerFailure": {
          "value": "No mechanism",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
          "sentiment": "bad"
        },
        "proposerFailure": {
          "value": "Cannot withdraw",
          "description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
          "sentiment": "bad",
          "orderHint": null
        }
      }
    }

  • scalingTechnology +7 -7 Viewed

    {
      "architectureImage": "polygon-cdk-validium",
      "architectureImage": "agglayer-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 Sequencer, after being signed by the DAC members.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "PolygonValidiumEtrog.sol - Etherscan source code, sequenceBatchesValidium function",
              "title": "Validium.sol - Etherscan source code, sequenceBatchesValidium function",
              "url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code#F1#L91"
            }
          ]
        }
      ],
      "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": "The mechanism for allowing users to submit their own transactions is currently disabled.",
        "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. A mechanism for users to submit their own batches is currently disabled.",
        "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-sovereign'). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum 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.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`](https://evm.storage/eth/19489007/0x5132a183e9f3cb7c848b0aac5ae0c4f0491b7ab2/_legacyBatchNumToStateRoot#map) variable of AgglayerManager, is available [here](https://github.com/0xPolygonHermez/zkevm-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
        "dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/transaction-batching/)."
        "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/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 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. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "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 Validium 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": "polygoncdk"
    }

  • livenessConfig +1 -6 Viewed

    {
      "duplicateData": {
        "from": "stateUpdates",
        "to": "proofSubmissions"
      }
    }
    null

• ternoa +10 -15 Viewed

  • scalingRisks +1 -1 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "Validity proofs (ST, SN)",
          "description": "STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.",
          "sentiment": "good",
          "orderHint": null,
          "executionDelay": 0,
          "secondLine": "No execution delay"
        },
        "dataAvailability": {
          "value": "External (DAC)",
          "description": "Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC) with a threshold of 1/1 that is tasked with protecting and supplying the data.",
          "sentiment": "bad",
          "orderHint": 1
        },
        "exitWindow": {
          "value": "None",
          "description": "Even though there is a 3d Timelock for upgrades, forced transactions are disabled.",
          "description": "Even though there is a 3d Timelock for upgrades, there are no forced transactions and thus no way to exit during operator censorship or downtime.",
          "sentiment": "bad",
          "orderHint": -1,
          "warning": {
            "value": "The Security Council can remove the delay on upgrades.",
            "sentiment": "bad"
          }
        },
        "sequencerFailure": {
          "value": "No mechanism",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
          "sentiment": "bad"
        },
        "proposerFailure": {
          "value": "Cannot withdraw",
          "description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
          "sentiment": "bad",
          "orderHint": null
        }
      }
    }

  • scalingTechnology +8 -8 Viewed

    {
      "architectureImage": "polygon-cdk-validium",
      "architectureImage": "agglayer-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 Sequencer, after being signed by the DAC members.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "PolygonValidiumEtrog.sol - Etherscan source code, sequenceBatchesValidium function",
              "url": "https://etherscan.io/address//0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code#F1#L91"
              "title": "Validium.sol - Etherscan source code, sequenceBatchesValidium function",
              "url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code#F1#L91"
            }
          ]
        }
      ],
      "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": "The mechanism for allowing users to submit their own transactions is currently disabled.",
        "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. A mechanism for users to submit their own batches is currently disabled.",
        "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-sovereign'). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum 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.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`](https://evm.storage/eth/19489007/0x5132a183e9f3cb7c848b0aac5ae0c4f0491b7ab2/_legacyBatchNumToStateRoot#map) variable of AgglayerManager, is available [here](https://github.com/0xPolygonHermez/zkevm-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
        "dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/transaction-batching/)."
        "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/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 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. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "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 Validium 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": "polygoncdk"
    }

  • livenessConfig +1 -6 Viewed

    {
      "duplicateData": {
        "from": "stateUpdates",
        "to": "proofSubmissions"
      }
    }
    null

• wirex +11 -16 Viewed

  • scalingRisks +1 -1 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "Validity proofs (ST, SN)",
          "description": "STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.",
          "sentiment": "good",
          "orderHint": null,
          "executionDelay": 0,
          "secondLine": "No execution delay"
        },
        "dataAvailability": {
          "value": "External (DAC)",
          "description": "Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC) with a threshold of 1/2 that is tasked with protecting and supplying the data.",
          "sentiment": "bad",
          "orderHint": 0.5
        },
        "exitWindow": {
          "value": "None",
          "description": "Even though there is a 3d Timelock for upgrades, forced transactions are disabled.",
          "description": "Even though there is a 3d Timelock for upgrades, there are no forced transactions and thus no way to exit during operator censorship or downtime.",
          "sentiment": "bad",
          "orderHint": -1,
          "warning": {
            "value": "The Security Council can remove the delay on upgrades.",
            "sentiment": "bad"
          }
        },
        "sequencerFailure": {
          "value": "No mechanism",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
          "sentiment": "bad"
        },
        "proposerFailure": {
          "value": "Cannot withdraw",
          "description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
          "sentiment": "bad",
          "orderHint": null
        }
      }
    }

  • scalingTechnology +9 -9 Viewed

    {
      "architectureImage": "polygon-cdk-validium",
      "architectureImage": "agglayer-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 Sequencer, after being signed by the DAC members.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "PolygonValidiumStorageMigration.sol - Etherscan source code, sequenceBatchesValidium function",
              "title": "Validium.sol - Etherscan source code, sequenceBatchesValidium function",
              "url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code#F1#L91"
            }
          ]
        }
      ],
      "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": "The mechanism for allowing users to submit their own transactions is currently disabled.",
        "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. A mechanism for users to submit their own batches is currently disabled.",
        "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-sovereign'). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum 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.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 WirexPayChainValidium contract."
        "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/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 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. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "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 Validium 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": "polygoncdk"
    }

  • livenessConfig +1 -6 Viewed

    {
      "duplicateData": {
        "from": "stateUpdates",
        "to": "proofSubmissions"
      }
    }
    null

• witness +10 -15 Viewed

  • scalingRisks +1 -1 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "Validity proofs (ST, SN)",
          "description": "STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.",
          "sentiment": "good",
          "orderHint": null,
          "executionDelay": 0,
          "secondLine": "No execution delay"
        },
        "dataAvailability": {
          "value": "External (DAC)",
          "description": "Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC) with a threshold of 1/2 that is tasked with protecting and supplying the data.",
          "sentiment": "bad",
          "orderHint": 0.5
        },
        "exitWindow": {
          "value": "None",
          "description": "Even though there is a 3d Timelock for upgrades, forced transactions are disabled.",
          "description": "Even though there is a 3d Timelock for upgrades, there are no forced transactions and thus no way to exit during operator censorship or downtime.",
          "sentiment": "bad",
          "orderHint": -1,
          "warning": {
            "value": "The Security Council can remove the delay on upgrades.",
            "sentiment": "bad"
          }
        },
        "sequencerFailure": {
          "value": "No mechanism",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
          "sentiment": "bad"
        },
        "proposerFailure": {
          "value": "Cannot withdraw",
          "description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
          "sentiment": "bad",
          "orderHint": null
        }
      }
    }

  • scalingTechnology +8 -8 Viewed

    {
      "architectureImage": "polygon-cdk-validium",
      "architectureImage": "agglayer-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 Sequencer, after being signed by the DAC members.",
          "risks": [
            {
              "category": "Funds can be lost if",
              "text": "the external data becomes unavailable.",
              "isCritical": true
            }
          ],
          "references": [
            {
              "title": "PolygonValidiumStorageMigration.sol - Etherscan source code, sequenceBatchesValidium() function",
              "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code#F1#L126"
              "title": "Validium.sol - Etherscan source code, sequenceBatchesValidium function",
              "url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code#F1#L91"
            }
          ]
        }
      ],
      "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": "The mechanism for allowing users to submit their own transactions is currently disabled.",
        "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. A mechanism for users to submit their own batches is currently disabled.",
        "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-sovereign'). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum 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.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`](https://evm.storage/eth/19489007/0x5132a183e9f3cb7c848b0aac5ae0c4f0491b7ab2/_legacyBatchNumToStateRoot#map) variable of AgglayerManager, is available [here](https://github.com/0xPolygonHermez/zkevm-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
        "dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/transaction-batching/)."
        "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/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 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. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
      "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 Validium 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": "polygoncdk"
    }

  • livenessConfig +1 -6 Viewed

    {
      "duplicateData": {
        "from": "stateUpdates",
        "to": "proofSubmissions"
      }
    }
    null

• xlayer +39 -4 Viewed

  • scalingRisks +1 -1 Viewed

    {
      "self": {
        "stateValidation": {
          "value": "None",
          "description": "Currently the system permits invalid state roots. 'Pessimistic' proofs only validate the bridge accounting.",
          "sentiment": "bad",
          "orderHint": null
        },
        "dataAvailability": {
          "value": "External",
          "description": "Proof construction and state derivation rely fully on data that is NOT published onchain.",
          "sentiment": "bad"
        },
        "exitWindow": {
          "value": "None",
          "description": "There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.",
          "sentiment": "bad",
          "orderHint": 0
        },
        "sequencerFailure": {
          "value": "No mechanism",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring.",
          "description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
          "sentiment": "bad"
        },
        "proposerFailure": {
          "value": "Cannot withdraw",
          "description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
          "sentiment": "bad",
          "orderHint": null
        }
      }
    }

  • scalingTechnology +38 -3 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-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.",
          "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'). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum 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."
            },
            {
              "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/learn/agglayer/pessimistic_proof"
              "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": "polygoncdk"
    }