zkSync is Live! Bringing Trustless, Scalable Payments to Ethereum

Experience the magic of the first zkRollup with no application-specific trusted setup.

Six months ago we introduced our vision for zkSync: a trustless L2 scaling solution to enable mass adoption of public blockchains. Today, we invite you to celebrate with us the first big milestone on our roadmap — the launch of zkSync v1.0 on mainnet.

This release solves an acute problem in the Ethereum ecosystem: transactions have become expensive and unreliable due to soaring gas fees. Every month, ETH and ERC20 token transfers alone cost Ethereum users over $2M in gas fees (and rising). zkSync can massively reduce these costs while gradually enabling VISA-scale throughput of up to 2,000 TPS.

What is zkSync?

zkSync is built using Matter Labs’ zkRollup technology: a combination of cutting-edge research in zero-knowledge proofs with on-chain data availability. This approach boasts impressive security properties: if implemented correctly, funds placed in a zkRollup are as safe as in the underlying L1. More on this below.

While security is and always will be the topmost priority of the zkSync architecture, we’ve obsessively seek out the most elegant design ideas to enable unmatched UX and a smooth developer experience. Here are the main highlights:

• Transaction fees designed to be predictably low long term (< $0.01 / tx).
• Fees payable in the token being transferred (no hassle with gas for users).
• Zero-cost for off-chain account creation.
• L2 transfers to any Ethereum address (including yet-to-be-deployed contracts!)
• Instant confirmations on transactions and finality within minutes.
• Withdraw to L1 15 minutes after the block is filled.
• Intuitive UX that works with any Ethereum wallet.

The best way to understand the system is to try out zkSync yourself. To kickstart your journey into the world of zkRollups, we created a 1-click faucet that will award the first 500 users with a souvenir Matter Labs Trial Token ($MLTT). After you withdraw funds to the mainnet, it will record proof that you were in the early zkRollup gang.

Go ahead and give it a try, it should only take 2 minutes!

While zkSync v1.0 scales crypto payments on Ethereum today, it also lays the technological foundation for the next steps on our roadmap: enabling smart-contract functionality, privacy, and cryptographically secured censorship-resistance.

Our ultimate goal is scalable, privacy-preserving, fair, and fully permissionless crypto infrastructure for billions of people, while making it easy and useful to build on for developers.

Start building on zkSync today!

zkSync is fully permissionless, you can start using it right now. Integrating it into your project requires only a few lines of code: zksync-js SDK follows the best practices of the client libraries and is modeled after the state-of-the-art ethers-js.

Check out the getting started tutorial on our developer portal.

We are more than happy to offer help, discuss the specifics of your use-case, and provide any support you might require! Please get in touch.

If your use-case involves some complex logic, such as multisig, exchange, escrow, atomic swaps, minting/burning, or even more sophisticated smart contracts, we’d be particularly interested to assist.

While our future releases will enable powerful smart contracts on Zinc, a lot of things can already be achieved today with zkSync v1.0.

To learn more about how zkSync works, you’ll find exhaustive information in the FAQ and documentation area on zksync.io. In the remainder of this post, we focus on the two major properties of the protocol: security and extensibility.

Secure like mainnet

The core technology of zkSync — zkRollup — is the only L2 scaling approach that can provide the same passive security guarantees as L1. This means once you have confirmation that funds landed in your zkSync account, you can go offline for a year, come back, and be sure you will be able to recover your assets without any external help. Your zkSync deposit is completely immune to any manipulations or attacks on the zkSync operators.

This is absolutely unique among the existing L2 scaling solutions: all other approaches require active security efforts, which means their operators need to do some ongoing work to keep funds safe. This increases the attack surface and threats of other kinds (for example in some cases your account can be frozen or seized by the operators).

Security of zkSync users’ assets is of paramount importance to us. We are following very strict development and DevOps security practices, have conducted thousands of transactions in load tests, and covered our code extensively with unit and integration tests.

Further, zkSync protocol, smart contracts, and zero-knowledge circuits have been audited by one of the most respected expert groups in the zero-knowledge space: ABDK Consulting (the team that co-authored Poseidon, Equihash and Argon2 hash functions and conducted the cryptanalysis of Jarvis cipher, STARK-friendly hash function Friday, AES, ALE, Catena, RC4, IDEA, and many other cryptographic schemes and protocols).

Despite the thorough audit, out of extra precaution we’ve decided to release zkSync v1.0 as a public beta. Practically this means one thing: contracts can be updated by Matter Labs after a shorter notice period, which allows us to quickly respond to any unexpected situation. Users will be notified about the planned upgrade via smart contracts events (an integration with spells.fyi service will soon be available). If users disagree with upcoming changes, they will have the notice period to submit an exit request on L1. By design, no upgrade will go through until all exit requests are processed. The upgrade authorization is secured by a multisig controlled with separate cold-wallets. We will gradually increase the notice period until, eventually, a pure opt-in upgrade mechanism is implemented to remove any potential risks of a mass exit and enact 100% passive security for zkSync accounts.

While zkSync UI will work with any Ethereum wallet, there is an important caveat. The SNARK-friendly signature scheme used in zkSync (a variant of Schnorr) is different from the ECDSA scheme used in Ethereum. We have a Metamask snap prototype with our signature scheme integrated (will be published as soon as snaps are ready for mainnet), as well as a partnership program underway to provide native support for mobile, desktop, and hardware wallets. Until then, zkSync account control keys are handled by the zkSync UI in the browser, which is not ideal from a security perspective. To mitigate this attack vector, we implemented a 2-factor security mechanism: for every transaction, a plain-text authorization must be signed with the native Ethereum signature, which is checked by our servers before the transaction is included in the rollup block. This way, even if our UI website gets hacked, the attacker won’t be able to exploit it. At the same time, we expect native integrations to follow quickly making this security precaution unnecessary.

zkSync is the first zkRollup with no app-specific trusted setup — why this is a game-changer

TL;DR:

• Trusted setup is hard, it requires lots of experts and community attention to be secure. The previous generation of SNARKs required application-specific trusted setups, vastly reducing security and applicability of zkRollup tech.
• zkSync is the first zkRollup with a universal trusted setup. We reuse the results of the most secure MPC ceremony ever conducted.
• This enables us to easily and securely iterate on zkSync design, add extensions, increase throughput, add smart contracts, and implement privacy.

The previous generation of SNARK-based blockchain tech (Zcash, Tornado cash, Loopring) used a proof system called Groth16. While it was a state of the art protocol at the time of its release in 2016, we’ve seen a Cambrian explosion in zero-knowledge proof protocols over the last year that have massively improved on Groth16 — especially in regard to the setup of the Common Reference String (CRS).

The CRS is better known as “the trusted setup”. Before SNARK proofs can be generated, CRS must be created once, usually in the course of a Multi-Party-Computation (MPC) ceremony with a number of participants. If at least one of these participants was honest and has securely deleted the entropy (randomness) of their contribution, SNARKs produced by using this CRS are considered secure.

The trusted setup MPC is a huge logistical and operational security challenge. But Groth16 turns it into a logistical and security nightmare — by requiring an application-specific trusted setup. What this means is that a trusted setup needs to be done separately for each application and each update of the logic in this application (every change, every bugfix). Consider the following:

• The trusted setup protocol needs to be peer-reviewed with a high degree of scrutiny. An error in the protocol specification of trusted setup for Zcash’s Sprout introduced a severe security vulnerability. You want a lot of public attention to your trusted setup. This is hard to do frequently, especially when bound to a single application.
• The code of the trusted setup implementation must be thoroughly reviewed to eliminate backdoors and weak spots. Ideally, you need multiple independent implementations.
• Participants of a trusted setup must follow strict security procedures to make sure they have not been compromised: run it in secure environments (definitely not in a browser), ideally on freshly bought air-gapped machines.
• Your users want to see participants they personally know and consider trustworthy plus security-savvy. This is hard to achieve with project-specific setups.
• Finally, the sheer logistic complexity of the procedure (for a scalability-oriented trusted setup you need many Gb download/upload, and hours of computation while guarding security) makes it very hard for people to participate on a consistent basis.

The ideal situation is to get rid of it entirely, or at the very least have to do it only once.

A few efficient proof systems have recently appeared that are transparent — i.e. do not require a trusted setup — such as STARKs, Halo, and SuperSonic. They looked very promising, especially STARKs, as other systems were too expensive to verify on Ethereum. So the Matter Labs team experimented a lot in this direction: we released Hodor, our STARK prover implementation, and later developed RedShift, a hybrid transparent proof system that combines the best of the SNARK and STARK worlds.

Unfortunately, STARK and RedShift proofs are still quite expensive to verify in terms of gas. This makes their current deployment for zkRollups problematic. More work needs to be done to make them efficient enough for this task.

However, we now have a new class of proof systems called SNORKs: SNARKs with a universal and updateable trusted setup. This means a setup is still required, but only once, and can be later reused by many applications. The first of its kind was Sonic (Matter Labs created the first implementation of a succinct version of it), but later more efficient ones followed. Today, PLONK is the most advanced and peer-reviewed proof system of this kind.

In Fall 2019 Matter Labs participated in the Ignition MPC ceremony for PLONK organized by AZTEC Protocol. Further participants included Vitalik Buterin and a number of other prominent members of the crypto community. Buterin also created an independent implementation of the participant’s software. zkSync v1.0 uses PLONK with the CRS from Ignition as its proof system.

This one-time trusted setup means we can rapidly iterate on zkSync design and implement new features or extensions without losing any security properties.

For a pairing friendly elliptic curve available in Ethereum, the maximum PLONK circuit size is 2²⁶. This leads to a limitation of the maximum block size in zkSync v1.0 which caps throughput at 300 TPS — instead of the 2,000 TPS that both our tech stack and Ethereum bandwidth would enable today. However, this is not a problem for two reasons:

1. The current capacity exceeds the average transaction load of Paypal (200 TPS). We believe that it will be perfectly sufficient for the first few months of zkSync operation.
2. More importantly, there are few effective recursion strategies available for PLONK even without cycles of elliptic curves. We have implemented several variants of recursion and will choose one of the strategies based on more exhaustive tests. Recursion allows us to make blocks in zkSync v1.1 uncapped without reimplementing the already audited basic block circuit. Moreover, it is the key to the future implementation of privacy and smart contracts. We will provide more details later in a separate post.

As we said at the start, our goal is scalable, privacy-preserving, resilient, fair, fully permissionless blockchain technology for billions of people. Today we start with a scalability solution that meets all these needs, sans privacy. Once at scale, we will do the same for privacy on Ethereum.

To Scalability and beyond! Got questions?

The zkSync website contains a comprehensive FAQ and documentation area.

Want to learn more or discuss a partnership? Talk to us!

Join the conversation with us on Twitter: @the_matter_labs

We are incredibly thankful to everybody who helped to make this milestone possible: to our investors and advisors for their ongoing assistance; to @vbuterin for his old (2017!) blog posts that inspired us to dive into the world of zero-knowledge proofs, and for his idea of zkRollup; to Sean Bowe for “bellman” — the golden standard of how cryptography implementation should look like; to the Ethereum Foundation — and personally to @BarryWhitehat and Albert Ni — for believing in us and for their support during the most critical early phase of the project; to Eli Ben-Sasson for the inspiration to bring ZKPs to the new level; and to the ZKP community, especially Mary Maller, Zac Williamson and Ariel Gabizon for the ideas and incredible work on proof systems with universal trusted setups.