“Only the paranoid will survive.” — Andy Grove, CEO of Intel
In preparation for the launch of NFTs, swaps and zkEVM, we have noticed exponential growth in the number of users and funding for zkSync. However, there are often risks and trust assumptions associated with new protocols in the early stages of development that we feel it is important to bring to the attention of new and existing users.
The risks come from the innovative technology applied to Layer 2 on the one hand, and the potential centralization trend of these solutions on the other. Like most pragmatic teams, zkSync has embarked on a path of incremental decentralization and is actively pioneering innovations to enhance the security and scalability of the ethereum ecosystem.
A few points to note here are.
We cannot guarantee that the project is free of vulnerabilities. However, we will take into account the latest and best security practices in the industry and work with top auditing firms to audit the project’s contracts, circuitry and underlying cryptography to minimize the likelihood of vulnerabilities. This risk is present in all new projects built on ethereum. This is especially true for our project, as the zero-knowledge proof technology adds to the innovation and complexity of the project.
zkSync will remain upgradable until the functional scope is stabilized. However, upgrades will be controlled by the protocol governance mechanism and will require a 4-week lock-in period (see below for details).
zkSync currently relies on a trusted setup. We use the results of a multi-party computational ritual with over 200 participants (including Vitalik Buterin, EtherFoundation, Consensys, Argent, and Matter Labs, among others). As long as one participant is honest, our system is secure. Although this trust assumption does not seem to be a big problem at the moment, we still intend to switch to RedShift in the future, so that we no longer need any trustworthy settings.
To reduce the impact of (1) and (2), we now adopt a multi-layered security strategy.
zkSync’s Triple Security Solution
Security through isolation and redundancy
zkSync Security Council
- Security through isolation and redundancy
Since our Layer 1 smart contract is very lightweight by design (only a few hundred lines of code), we do not expect serious problems in this part. However, the zero-knowledge proof technology part is not only more code, but also more complex, and thus will be more risky.
In fact, the cryptography part is also less likely to be problematic. If we compare smart contract vulnerabilities to a sudden tsunami, then a cryptography vulnerability is like a flood triggered by a continuous rainstorm: the ground will soon be flooded, but people are actually concentrated on the roofs of skyscrapers with plenty of time to evacuate. Often, newly discovered vulnerabilities are only exploitable in less secure environments because the security threshold in real production environments is much higher, resulting in multiplying the cost of attacks. In the famous RSA cracking challenge, for example, it took only one month to crack a 100-bit password, but it took nearly 30 years to crack a 250-bit password. However, in the real world, systems use 2048-bit and higher passwords.
To add an additional layer of protection against vulnerability attacks in the zero-knowledge proof technique section, we use a double insurance measure.
Isolation: Only blocks submitted by authorized sequencers can submit state transitions to the zkSync Layer 1 smart contract. We will soon move to collective sequencers protected by PoS consensus of multiple validators.
Redundancy: Each transaction submitted to the sequencer is verified by a simple execution before being packed into a block.
Thus, even if there is a vulnerability in the zero-knowledge proof circuit or the underlying cryptography such that a do-gooder could generate a zero-knowledge proof for an invalid transaction, it is not easy to exploit this vulnerability.
To submit an invalid block to rollup, an attacker would have to break both the cryptography and sequencer/PoS consensus.
In order to discover potential vulnerabilities early, we will introduce a low security threshold vulnerability bounty program for white hat hackers.
- Trust-minimizing scalability
In the early stages of the zkSync protocol, scalability helps us innovate, iterate quickly, and fix vulnerabilities faster. If every upgrade (like Uniswap V2 to V3) required users to migrate assets, the user experience would be poor. However, scalability is a double-edged sword: it introduces additional trust assumptions and risks.
We strongly believe that users should not rely solely on the developer team or governance for security. Therefore, our zkRollup uses a priority queue/emergency exit mechanism to protect users from verifier scrutiny: you are free to exit zkSync regardless of verifier collaboration. however, if there is an undetected scalability backdoor, cool.
To help achieve a good balance in zkSync 2.0.
Initially, upgrades can be initiated through the zkSync governance mechanism, which requires a 4-week lockdown period before deployment. Even if the governance mechanism is significantly broken, the lockdown period allows enough time for users to exit via a priority queue/emergency exit mechanism.
The protocol is fixed (never to be upgraded again) after it has been fully tested, and users are asked to select a new version.
- zkSync Council
One final scenario we have to consider is that certain transactions could, in theory, cause a failure within zkEVM. If such transactions are committed to the priority queue and cannot be processed, the system will stop and go into emergency mode. Even if we fix this issue with an upgrade, it will take at least 4 weeks until the lockout period is over. In other words, all funds in zkSync will be frozen for 4 weeks or more.
To avoid this, 15 highly respected members of the ethereum community will step in in case of an emergency. zkSync Council consists of the following members.
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 Council will have a role if issues arise that cannot be resolved through the normal escalation process. The Council’s authority is limited to reducing the 4-week lockout period, but it is not part of zkSync governance and cannot bypass the governance mechanism to initiate an escalation.
With the help of the Gnosis Safe multi-signature mechanism, the zkSync Council will adhere to the following rules.
8/15 signatures can reduce the lockout period to 2 weeks.
10/15 signatures can reduce the lockout period to 1 week.
A 12/15 signature reduces the lockout period to 3 days.
To prevent the worst case scenario, any upgrade has a minimum lockout period. The Council is only a temporary measure to convince people that there is zero knowledge to prove security. When we switch to a purely selective escalation mechanism, the Council will no longer be needed.
The security of our users’ money has always been our top priority. When Matter Labs was founded 3 years ago, we chose to focus solely on zkRollup – the only Layer 2 scalable technology with the same security properties as Layer 1. Through user education, information transparency, and a triple security solution, we want users to feel comfortable interacting with zkSync.
If you have any questions about asset security, please join our discussions on Discord, Telegram, and Twitter.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/triple-security-solution-for-layer-2-solution-zksync/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.