ZKsync Lite
Badges
About
ZKsync Lite (formerly ZKsync) is a ZK Rollup platform that supports payments, token swaps and NFT minting.
Badges
About
ZKsync Lite (formerly ZKsync) is a ZK Rollup platform that supports payments, token swaps and NFT minting.
ZKsync 1.0 launch
2020 Jun 18th
ZKsync is live, bringing scalable payments to Ethereum using ZK Rollup technology.
Funds can be stolen if
Funds can be lost if
Users can be censored if
MEV can be extracted if
Sequencer failure
Force via L1State validation
ZK proofs (SN)SNARKs are zero knowledge proofs that ensure state correctness, but require trusted setup.
Exit window
7dUsers have 7d to exit funds in case of an unwanted upgrade. There is a 21d delay before an upgrade is applied, and withdrawals can take up to 14d to be processed.
Proposer failure
Use escape hatchUsers are able to trustlessly exit by submitting a zero knowledge proof of funds.
ZKsync Lite is a Validity proofs ensure state correctness
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.
Zero knowledge SNARK cryptography is used
Despite their production use zkSNARKs are still new and experimental cryptography. Cryptography has made a lot of advancements in the recent years but all cryptographic solutions rely on time to prove their security. In addition zkSNARKs require a trusted setup to operate.
Funds can be stolen if the cryptography is broken or implemented incorrectly.
All data required for proofs is published onchain
All the data that is used to construct the system state is published onchain in the form of cheap calldata. This ensures that it will always be available when needed.
No compression, transactions are always the same size.
There is no genesis file nor regenesis for ZKsync Lite. By default, all accounts were empty at the beginning.
The data format documentations 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 exit the system
Force exit allows the users to escape censorship by withdrawing their funds. The system allows users to force the withdrawal of funds by submitting a request directly to the contract onchain. The request must be served within a defined time period. If this does not happen, the system will halt regular operation and permit trustless withdrawal of funds.
Users can be censored if the operator refuses to include their transactions. However, there exists a mechanism to independently exit the system.
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. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular exit.
Emergency exit
If the enough time deadline passes and the forced exit is still ignored the user can put the system into Exodus Mode, disallowing further state updates. In that case everybody can withdraw by submitting a zero knowledge proof of their funds with their L1 transaction.
Funds can be lost if the user is unable to generate the non-trivial ZK proof for exodus withdraw.
The system uses the following set of permissioned addresses:
A Gnosis Safe with 4 / 7 threshold. This Multisig is the owner of Upgrade Gatekeeper contract and therefore is allowed to perform upgrades for Governance, Verifier and ZkSync contracts. It can also change the list of active validators and appoint the security council (by upgrading the ZkSync contract).
Those are the participants of the ZkSync Multisig.
The Security Council’s only role is to reduce the upgrade delay to zero if 9 of its members decide to do so. The council has 15 members which are hardcoded into the ZkSync contract. Changing the council requires a ZkSync contract upgrade.
Account receiving fees for listing tokens. Can be updated by ZkSync Multisig.
The system consists of the following smart contracts on the host chain (Ethereum):
The main Rollup contract. Allows the operator to commit blocks, provide ZK proofs (validated by the Verifier) and processes withdrawals by executing blocks. Users can deposit ETH and ERC20 tokens. This contract also defines the upgrade process for all the other contracts by enforcing an upgrade delay and employing the Security Council which can shorten upgrade times. This contract can store any token.
Upgrade delay: 21d or 0 if overridden by 9 of 15 Security Council
Implements ZK proof verification logic.
Upgrade delay: 21d or 0 if overridden by 9 of 15 Security Council
Keeps a list of block producers, NFT factories and whitelisted tokens.
Upgrade delay: 21d or 0 if overridden by 9 of 15 Security Council
This is the contract that owns Governance, Verifier and ZkSync and facilitates their upgrades. The upgrade constraints are defined by the ZkSync contract.
Allows anyone to add new ERC20 tokens to ZKsync Lite given sufficient payment.
Upgrade delay: No delay
Value Locked is calculated based on these smart contracts and tokens:
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).