ZKsync Era
Badges
About
ZKsync Era is a general-purpose ZK Rollup with full EVM compatibility.
$1.14 B
9.73%
- Users' withdrawals can be censored by the permissioned operators.
- Upgrades executed by actors with more centralized control than a Security Council provide less than 7d for users to exit if the permissioned operator is down or censoring.
Badges
About
ZKsync Era is a general-purpose ZK Rollup with full EVM compatibility.
...
Choose token
ZKsync (ZK)
Holdstation (HOLD)
zkSwap Finance (ZF)
USDC (USDC)
Zeek Coin (MEOW)
Zorro (ZORRO)
Staked Frax Ether (sfrxETH)
Frax Ether (frxETH)
Frax Price Index (FPI)
Frax (FRAX)
Frax Share (FXS)
Frax Price Index Share (FPIS)
Ether (ETH)USD Coin (USDC)
Koi (KOI)
Tether USD (USDT)
Wrapped BTC (WBTC)
Wrapped liquid staked Ether 2.0 (wstETH)
Mute.io (MUTE)
Rocket Pool ETH (rETH)
DEXTF Token (DEXTF)
Dai Stablecoin (DAI)
GOVI (GOVI)
LUSD Stablecoin (LUSD)
Pepe (PEPE)
Symbiosis (SIS)
DeversiFi Token (DVF)...
...
ZKsync Protocol Upgrade v24
2024 Jun 6th
A protocol upgrade that introduces a shared bridge and the foundation for other ZK stack chains.
Introduction of Boojum prover
2023 Jul 17th
Deployment of Boojum - new high-performance proof system.
Fair Onboarding Alpha and Rebranding
2023 Feb 16th
ZKsync 2.0 rebrands to ZKsync Era and lets registered projects and developers deploy on mainnet.
Funds can be stolen if
Funds can be lost if
Users can be censored if
MEV can be extracted if
Data 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.
Sequencer failure
Enqueue via L1Proposer 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 - The project calls itself a rollup.
- L2 state roots are posted to Ethereum L1.
- Inputs for the state transition function are posted to L1.
- A source-available node exists that can recreate the state from L1 data. Please note that the L2BEAT team has not verified the validity of the node source code. View code
- A complete and functional proof system is deployed.
- Users’ withdrawals can be censored by the permissioned operators.
- Upgrades executed by actors with more centralized control than a Security Council provide less than 7d for users to exit if the permissioned operator is down or censoring.
- Upgrades unrelated to on-chain provable bugs provide less than 30d to exit.
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 its facets and censoring transactions or stealing locked funds. Most permissions are inherited by it being the Owner of the StateTransitionManager (STM). 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 an Admin role. This role can manage fees, apply predefined upgrades, censor bridge transactions and revert batches. It cannot make arbitrary updates or access funds in the escrows.
Other roles include:
Validator: Proposes batches from L2 through the ValidatorTimelock, from where they can be proven and finally executed (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 ZKsync Era diamond and can be set by the Matter Labs Multisig through the STM. The actual Validator actors can be added and removed by the Admin 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 (Matter Labs Multisig) role and a SecurityCouncil role.
The system uses the following set of permissioned addresses:
This MultiSig is the current central Admin for upgradeability and configuration of the rollup system and can potentially steal all funds. This is a Gnosis Safe with 4 / 7 threshold.
Those are the participants of the Matter Labs Multisig.
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
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
Intermediary contract between the Validators and the ZKsync Era diamond that delays block execution (ie withdrawals and other L2 --> L1 messages).
Implements ZK proof verification logic.
Upgrade delay: No delay
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
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
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).
