ZKsync Era
Badges
About
ZKsync Era is a general-purpose ZK Rollup with full EVM compatibility.
$778.85 M
1.69%
Badges
About
ZKsync Era is a general-purpose ZK Rollup with full EVM compatibility.
ZKsync Protocol Upgrade v24
2024 Jun 6th
A protocol upgrade that introduces a shared bridge and the foundation for other ZK stack chains.
Funds can be stolen if
Funds can be lost if
Users can be censored if
MEV can be extracted if
Sequencer failure
Enqueue via L1Data availability
On chain (SD)All of the data (SD = state diffs) needed for proof construction is published on chain.
Exit window
NoneThere is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Proposer failure
Cannot withdrawOnly the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
ZKsync Era is a Zero knowledge STARK and SNARK cryptography is used
Despite their production use zkSTARKs and zkSNARKs proof systems are still relatively new, complex and they rely on the proper implementation of the polynomial constraints used to check validity of the Execution Trace. In addition zkSNARKs require a trusted setup to operate.
Funds can be lost if the proof system is implemented incorrectly.
All data required for proofs is published on chain
All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.
The node software is open-source, and its source code can be found here. The main node software does not rely on Layer 1 (L1) to reconstruct the state, but you can use this tool for that purpose. Currently, there is no straightforward method to inject the state into the main node, but ZKsync is actively working on a solution for this.
There have been neither genesis states nor regenesis.
Details on data format can be found here.
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.
ZKsync Era proof system Boojum can be found here and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found here.
The system has a centralized operator
The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can force any transaction via L1
If a user is censored by L2 Sequencer, they can try to force transaction via L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from L1 queue in an L2 block.
Users can be censored if the operator refuses to include their transactions.
Regular exit
Forced exit
If the user experiences censorship from the operator with regular exit they can submit their withdrawal requests directly on L1. The system is then obliged to service this request or halt all messages from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular exit.
The Matter Labs multisig (4 / 7) is able to instantly upgrade all contracts and manage all parameters and roles. This includes upgrading the shared contracts, the ZKsync Era diamond and other ZK stack diamonds and their facets and censoring transactions or stealing locked funds. Most permissions are inherited by it being the indirect Owner of the StateTransitionManager (STM) and Governor (owner) of the Governance contract. A security council is currently not used.
The current deployment allows for a subset of the permissions currently held by the Matter Labs Multisig to be held by a ChainAdmin role.
This role can manage fees, apply predefined upgrades, censor bridge transactions, manage Validator addresses and revert batches. It cannot make arbitrary updates or access funds in the escrows. This Admin role is usually set to a ChainAdmin contract which is itself owned by the Matter Labs Multisig (Thus not affecting their full permissions).
Other roles include:
Validator: Proposes batches from L2 through the ValidatorTimelock, from where they can be proven and finally executed (by the Validator through the ExecutorFacet of the diamond) after a predefined delay (currently 21h). This allows for freezing the L2 chain and reverting batches within the delay if any suspicious activity was detected, but also delays finality. The ValidatorTimelock has the single Validator role in the Zk stack diamond contracts and can be set by the Matter Labs Multisig through the STM. The actual Validator actors can be added and removed by the ChainAdmin in the ValidatorTimelock contract.
Verifier: Verifies the zk proofs that were provided by a Validator. Can be changed by calling executeUpgrade() on the AdminFacet from the STM.
A Governance smart contract is used as the intermediary for most of the critical permissions of the Matter Labs Multisig. It includes logic for planning upgrades with parameters like transparency and/or a delay.
Currently the delay is optional and not used by the multisig.
The optional transparency may be used in the future to hide instant emergency upgrades by the Security Council or delay transparent (thus auditable) governance upgrades. The Governance smart contract has two roles, an Owner (Governor role in the picture, resolves to Matter Labs Multisig) role and a SecurityCouncil role.
The system uses the following set of permissioned addresses:
This is a Gnosis Safe with 4 / 7 threshold. This MultiSig is the current central Admin for upgradeability and configuration of the rollup system and can potentially steal all funds.
Used in:
Those are the participants of the Matter Labs Multisig.
Can manage fees, apply predefined upgrades, censor bridge transactions and revert batches (Admin role).
Used in:
The system consists of the following smart contracts on the host chain (Ethereum):
The main Rollup contract. The operator commits blocks and provides a ZK proof which is validated by the Verifier contract then processes transactions. During batch execution it processes L1 --> L2 and L2 --> L1 transactions. This contract stores the following tokens: ETH.
Upgrade delay: No delay
Proxy used in:
Intermediary governance contract with two roles and a customizable delay. This delay is only mandatory for transactions scheduled by the Owner role and can be set by the SecurityCouncil role. The SecurityCouncil role can execute arbitrary upgrade transactions immediately. Currently the delay is set to 0s and the SecurityCouncil role is not used.
Upgrade delay: No delay
Proxy used in:
Intermediary governance contract that has the Admin (not upgradeability admin) role for the shared contracts and for ZKsync Era.
Intermediary contract between the Validators and the ZKsync Era diamond that delays block execution (ie withdrawals and other L2 --> L1 messages).
Proxy used in:
Implements ZK proof verification logic.
Upgrade delay: No delay
Proxy used in:
This bridge contract escrows all ERC-20s and ETH that are deposited to ZKsync Era - and in the future - other registered ZK stack chains. This contract can store any token.
Upgrade delay: No delay
Proxy used in:
Value Locked is calculated based on these smart contracts and tokens:
Shared bridge for depositing tokens to ZKsync Era and, in the future, other ZK stack chains.
Upgrade delay: No delay
Proxy used in:
Legacy bridge for depositing ERC20 tokens to ZKsync Era. Forwards deposits and withdrawals to the BridgeHub.
Upgrade delay: No delay
Bridge for depositing wrapped stETH (Lido) to ZKsync Era. These deposits and withdrawals do not go through the new shared BridgeHub.
Upgrade delay: No delay
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).
