GRVT

The main contract defining the Layer 2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.. OperatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. actions like commiting blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over., providing ZK proofs and executing batches ultimately target this contract which then processes transactions. During batch execution it processes L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. --> L2 and L2 --> L1 transactions.

• Roles:
  • getAdmin: GrvtZkEvmAdmin; ultimately GrvtChainAdminMultisig
  • getTransactionFilterer: GRVTTransactionFilterer
  • validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier: ValidatorTimelock

Contract that ‘verifies’ the data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. for validiums. This implementation only checks the correct formatting and does not serve as a DA oracle. Can be used by ZK stack validiums as the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. part of a DAValidator pair.

The main registry (hub) for all the contracts in the ZK stack cluster and central entrypoint for bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. transactions. Stores important mappings like from chainId to diamond address, from chainId to parent CTM, from chainId to base token etc. A clone of Bridgehub is also deployed on each L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. chain, but this clone is only used on settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. layers.

• Roles:
  • admin: EraChainAdminProxy, ProxyAdmin; ultimately EmergencyUpgradeBoard, Matter Labs Multisig
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

Aggregates remote bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. message roots from all ZK stack chains. To be used with the Gateway when deployed.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard

Asset deployment tracker where the ‘asset’ is a ChainTypeManager. The registering of asset IDs for ChainTypeManagers is necessary to be able to migrate them to a given settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. layer, for example the Gateway.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard

Contract that verifies the data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. of ethereum calldata and blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.. Can be used by ZK stack rollups as the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. part of a DAValidator pair.

Defines L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. diamond contract versions, creation and upgrade data and the proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. for all ZK stack chains connected to it. ZK chains are children of this central contract and can only upgrade to versions that were previously registered here. The current protocol version is 0,30,1.

• Roles:
  • admin: EraChainAdminProxy, ProxyAdmin; ultimately EmergencyUpgradeBoard, Matter Labs Multisig
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

The central upgrade contract and Governance proxy for all ZK stack contracts. Accepts successful DAO proposals from L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. and emergency proposals from the EmergencyUpgradeBoard. The three members of the EmergencyUpgradeBoard also have special roles and permissions in this contract.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
  • emergencyUpgradeBoard: EmergencyUpgradeBoard
  • guardians: Guardians
  • l2_protocol_governor: ProtocolTimelockController; ultimately ZkProtocolGovernor
  • securityCouncil: SecurityCouncil

Simple registry for allowed DA address pairs for the ‘rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup.’ data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. mode (can be permanently enforced with isPermanentRollup=true). Rollup DA address pairs (especially the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. part) usually point to contracts that validate if data was made available on Ethereum.

• Roles:
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

A governance proxy that lets GrvtChainAdminMultisig act through it.

• Roles:
  • owner: GrvtChainAdminMultisig
  • tokenMultiplierSetter: GrvtChainAdminMultisig

A governance proxy that lets Matter Labs Multisig act through it.

• Roles:
  • owner: Matter Labs Multisig

Verifies a zk-SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. proof using an implementation of the PlonKA zk-SNARK proving system introduced by Gabizon, Williamson and Ciobotaru in 2019 that allows proving custom circuits. Plonk is based on KZG polynomial commitments and thus requires a universal trusted setup. proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..

Verifies a zk-SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. proof using an implementation of the fflonk proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..

A router contract for verifiers. Routes verification requests to EraVerifierFflonk or EraVerifierPlonk depending on the supplied proof type.

• Roles:
  • owner: ProtocolUpgradeHandler

• Roles:
  • owner: EraChainAdminProxy

Canonical central asset escrow for all ZK stack chains.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

Specialized contract for managing chain assets, i.e. chain migrations.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

A simple contract that can be called by the ChainAdmin to emit notifications about chain migrations.

• Roles:
  • admin: ProxyAdmin; ultimately Matter Labs Multisig

Timelock contract allowing the queueing of transactions with a minimum delay of 0s.

• Roles:
  • canceller: ZkProtocolGovernor
  • executor: ZkProtocolGovernor
  • proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.: ZkProtocolGovernor
  • timelockAdmin: ProtocolTimelockController; ultimately ZkProtocolGovernor

The ZK token contract on ZKsync Era. Mintable through access control roles. Used for voting in the ZK stack governance system.

• Roles:
  • admin: ZkTokenProxyAdmin; ultimately ProtocolUpgradeHandler_l2Alias
  • defaultAdmin: ProtocolUpgradeHandler_l2Alias
  • minterAdmin: ZkTokenTimelockController; ultimately ZkTokenGovernor

• Roles:
  • owner: ProtocolUpgradeHandler_l2Alias

Timelock contract allowing the queueing of transactions with a minimum delay of 3d.

• Roles:
  • canceller: ZkTokenGovernor
  • executor: ZkTokenGovernor
  • proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.: ZkTokenGovernor
  • timelockAdmin: ZkTokenTimelockController; ultimately ZkTokenGovernor