# Security
# Security overview
zkSync protocol design document explicitly lists the protocol's cryptographic assumptions and security properties.
In a nutshell, the protocol's claim is that, given correct implementation and validity of cryptographic assumptions, funds placed into zkSync will have the same security guarantees as if they are held in an Ethereum account without any additional requirements on the user part. In particular:
- Users do not need to monitor the network.
- Private keys can be held in cold storage.
- Operators can not steal funds or corrupt the zkSync state in any way.
- Users can eventually withdraw their assets onto the mainnet, regardless of cooperation from zkSync operators.
Several mechanisms are used to fulfill these guarantees, discussed below.
# Validity proofs
zkSync is built on zkRollup architecture. This means, every single user transaction is verified by a smart contract on the Ethereum mainnet by means of verifying the proof of the validity of the block. Thus, no operator can ever move the system into an incorrect state or take users money.
See this article for a further overview of the benefits of the validity proofs.
# Priority queue
In the ultimate emergency case of all operators being shut down or becoming unresponsive, the emergency exit mechanism ensures that users will keep control of their assets. It works as follows.
- If transactions of a user are being for any reason ignored by the operator, an exit request can be submitted directly on mainnet into the priority queue.
- Operators are obliged to process priority queue requests within a short time window (~1 week).
- In case the operators fail to process the requests, the system enters exodus mode and every user can immediately exit all of their assets by making a direct transaction on the Ethereum mainnet.
# Upgrade mechanism
The version 1.0 of zkSync protocol comes with a contract upgrade mechanism in order to facilitate faster design iterations. However, users have a fundamental right to opt-out of a future upgrade. A new upgrade must be announced via the zkSync contract and all users get 4 week notice period to exit in case they don't like the changes.
WARNING: the beta will be deployed with 1 day notice period, which will soon be bumped up to 1 week, then to 2 weeks, and finally to 4 weeks. In the future, this opt-out mechanism will be replaced by a strict opt-in.
# Cryptography used
Although zkSync is built on some of the most cutting-edge cryptography (such as PLONK and RedShift), we were very conservative with respect to security choices made in the protocol. Every component relies exclusively on well established cryptographic assumptions widely considered secure in the academic and professional security community.
# Primitives
| Primitive | Application | Cryptographic assumption |
|---|---|---|
| PLONK | Proof system (v1) | 1, 3 |
| RedShift | Proof system (v2) | 1 |
| SHA256 | Hash function | 1 |
| Rescue | Hash function | 1, 2 |
| muSig | Signature scheme | 1, 2, 3 |
# Cryptographic asssumptions
# Universal CRS setup
The version 1.0 of zkSync protocol is using the PLONK proof system which requires a "trusted setup" of a Common Reference String (CRS). In PLONK, this setup can be done once and be reused by any number of applications (this is called Universal CRS). If at least one participant deletes the entropy (randomness) used to provide their contribution, the setup is secure. Having universal and not application-specific setup significantly reduces trust assumptions, because larger number of prominent and respected members of the community have incentive to participate in it, and more scrutiny can be expected around the trusted setup ceremony.
Another big advantage of a universal CRS is that updates and bugfixes do not require their own trusted setup ceremonies (which are very difficult from the logistical and security perspectives).
Matter Labs participated in the global Ignition trusted setup ceremony for PLONK on BN256 elliptic curve, coordinated by AZTEC protocol:
| Participation address | 0x04a23ba68e4469061cd461e8b847e820d4ced948 |
| Transcript hash | 0x1f6647d91a9e667173640b67b654cabc81ceee98d6100f259788afb34a3fc529 |
| Signature | 0x3f4ff7b9a6668c23c9ba45d73d1d9d0902b881191d97b307969b63f52296f2326d437ea04dd67a2ebe57a691025d7d31bb0dae88e8023a0d9b15ad599c3eb9351b |
The ceremony ran from October 2019 until December 2019, with 176 participants from over 30 countries collaborating to compute a secure database of encrypted points, including Vitalik Buterin and other prominent members of the crypto community. Full ceremony transcript with the list of indviduals and organizations who claimed their contribution is available here. You can use this script to verify the contributions of the listed participants.
Despite relying on a universal trusted setup, we argue that zkSync can be called a fully trustless protocol. The reason for this is that there are no systems without some form of a trusted setup. Most users do not personally verify and compile the source code of their wallets, full nodes, mining software, and certainly do not verify the circuits of the hardware all these things run upon. In our opinion, the ease of concealed collusion of developers and experts in these systems is much higher than in a trusted setup with hundreds of well-known participants. At the same time, the ongoing operation of zkSync requires zero trust from any party whatsoever, which is unique among all L2 scaling solutions.
Nonetheless, we encourage you to check the list of the contributors of the Ignition ceremony and make your own opinion on whether there is at least one trustworthy person or organisation among them. And in the future, we strive to eliminate trust assumptions altogether by embracing a transparent zero-knowledge proof system such as RedShift (developed by Matter Labs).
# Security audit
The audit by ABDK Consulting for zkSync v1.0 protocol is complete, the results are available here. The audit scope includes the protocol design, applied cryptography, smart contracts and zero-knowledge circuits.