Security by Isolation and Redundancy, Trust-Minimized Upgradability, and the Introduction of zkSync’s Security Council
“Only the paranoid survive.” — Andy Grove, CEO of Intel
As we prepare for the launch of NFTs, swaps, zkEVM, and an exponential increase in users and capital flow into zkSync, we find it necessary to both warn new users and remind current users of the risks and trust assumptions associated with using new protocols during the early stages of their development.
The risks stem from both the technological novelties applied in L2 and from the potential increase of centralization in these solutions. As with most pragmatic teams, zkSync is taking a path of progressive decentralization to rapidly innovate and rapidly deliver on security and scalability for the Ethereum ecosystem.
Here are the main things to be aware of:
- Zero bugs cannot be guaranteed. But the probability of bugs will be minimized by following the industry’s latest security best practices and getting audits by leading auditing firms that cover contracts, circuits, and the underlying cryptography. This risk applies to all new applications being built on Ethereum, but is amplified in our case by the novelty and complexity of zero-knowledge proof technology.
- zkSync will remain upgradable until the functionality scope is stabilized. However, the upgradability will be controlled by protocol governance and is subject to a 4-week timelock which we discuss further below.
- zkSync currently relies on a trusted setup. We use the results of a ceremony with over 200 participants (including Vitalik Buterin, Ethereum Foundation, Consensys, Argent, Matter Labs, and many others), and our system is secure if at least one of them was honest. Although we haven’t yet met a blockchain project for whom this assumption would be a big concern, we still intend to switch to RedShift in the future, which does not require any trusted setup at all.
To mitigate the impact of (1) and (2) we are committing to the following multi-layer security strategy.
- Security by Isolation and Redundancy
- Trust-Minimized Upgradeability
- zkSync Security Council
Because our L1 smart contracts are very lightweight by design (comprising only a few hundred lines of code), we don’t expect serious issues with them. The ZKP side is riskier due to larger code volume and the added complexity of cryptography.
In reality, the cryptography part is also unlikely to cause problems. If we were to compare smart contract exploits to a sudden Tsunami, a cryptographic exploit is like a gradual rain flooding: the ground floor can be affected quickly — but everyone actually lives on top of a skyscraper and has enough time to evacuate. Newly discovered vulnerabilities are typically only exploitable at a much lower security threshold than what is used in production because the cost of attack grows exponentially. For example, during the famous RSA challenge, it took only a month to break the 100 bit cipher, but almost 30 years to break the 250 bit one, while real-world systems use 2048 bits and above.
To put an additional layer of protection against bugs and exploits on the ZKP side, our approach is twofold:
- Isolation: Only blocks submitted by an authorized sequencer will be allowed to commit a state transition to the zkSync L1 smart contract. We will soon switch to a collective sequencer secured by a multi-validator consensus with PoS.
- Redundancy: Every transaction submitted to the sequencer(s) will be validated by simple execution before inclusion in the block.
Thus, if there is a vulnerability in the ZKP circuits or underlying cryptography, such that a zero knowledge proof could be generated for an invalid transaction, it won’t be easily exploitable.
To submit an invalid block to the rollup, the attacker must break through both the cryptography AND the sequencer/PoS consensus.
To catch potential exploits early, a big bug bounty with much lower security threshold will be set up for the whitehat hackers.
Upgradability in the beginning stages of the zkSync protocol allows us to innovate, iterate quickly, and fix bugs faster. It would be a massive UX issue if users had to migrate their assets every time there was a new upgrade (think moving from Uniswap v2 to v3 every few months). But upgradability is a double edged sword: it comes with additional trust assumptions and increased risk.
We strongly believe users should not rely on the developer team or governance alone for security. So, our zkRollup has a priority queue / emergency exit mechanism to protect users from censorship by validators: you will always be able to exit zkSync regardless of validator coordination. But having an unchecked upgradeability backdoor would completely defeat this purpose.
To find a good balance for zkSync 2.0:
- Initially, upgrades can be initiated by zkSync governance with a timelock of 4-weeks before it is deployed. Even if the majority of governance was corrupted, the timelock would give users time to opt out via our priority queue / emergency exit mechanism.
- After the protocol has been battle tested, it will become immutable (can no longer be upgraded) and users will be asked to opt into new versions.
There is one last case we must account for. It is theoretically possible to have a bug where certain transactions cause the zkEVM to fail internally. If such a transaction is submitted to the priority queue and cannot be processed, the system will stop and enter emergency mode. An upgrade fixing the issue cannot happen faster than the timelock period of 4 weeks, which means all capital in zkSync will be frozen for 4 weeks or more.
To prevent such events, 15 respected members of the Ethereum community agreed to step in in the case of emergency. The zkSync Security Council is comprised of the following members:
- Aave
- Itamar Lesuisse (Argent)
- Mike McDonald (Balancer)
- James Prestwich (cLabs)
- Michael Egorov (Curve)
- Jack Baumruk (Dekrypt)
- Haseeb Qureshi (Dragonfly)
- Justin Drake (Ethereum Foundation)
- Stefan George (Gnosis)
- Baek Kim (Hashed)
- Chris Burniske (Placeholder)
- Nick Grossman (USV)
- Will Harborne (ZK Validator)
- Sergej Kunz (1inch)
- Lasse Clausen (1kx)
The security council helps in situations that cannot be resolved through a normal upgrade process. Their power is restrained to the ability to shorten the 4-week timelock notice period. They are not part of zkSync governance, and cannot bypass governance to initiate upgrades.
Enforced by our smart contracts, the rules will be as follows:
- 8/15 signatures can shorten the timelock to 2 weeks.
- 10/15 signatures can shorten the timelock to 1 week.
- 12/15 signatures can shorten the timelock to 3 days.
A minimal timelock will always remain to protect against the worst possible case. The Security Council is only a temporary measure to bootstrap trust in the security of zero-knowledge proofs. After we switch to a pure opt-in upgrade mechanism, it will no longer be required.
The security of user funds has been our top priority since day 0. When Matter Labs was formed 3 years ago, we chose to focus only on zkRollups — the only L2 scaling technology that offers the same security properties as L1. We hope that through education, transparency, and our 3-factor approach, users will feel safe when interacting with zkSync.
If you have any questions on the security of your funds, please join the discussion in our Discord, Telegram, and Twitter.
