zkSync v1.1 “Reddit Edition”: Recursion (up to 3,000 TPS!), Subscriptions, and More
Announcing zkSync v1.1 for The Great Reddit Scaling Bake-Off
We at Matter Labs could not be more excited about Reddit’s ambitious plan to onboard 500 million community members to a decentralized subreddit ownership model!
Our zkSync scaling solution (v1.0 is live on Ethereum mainnet) already fulfilled most of the requirements of the Great Scaling Bake-Off. Here is what we’ve done over the past month to enhance it:
- Implemented recursive ZK proofs, unlocking the full zkRollup capacity (up to 3,000 TPS)! A loadtest with 300,000 transactions is here.
- Presented exciting results of our FPGA research project: the world’s first practical hardware zkSNARK accelerator.
- Added support for automatic recurring payments (subscriptions).
- Enabled transactions for batching and paying fees in a separate token.
- Made burning and minting tokens possible inside zkSync.
- Designed and introduced zkPorter: a new future-proof architecture to scale data availability.
You will find a detailed technical description of the new features at the end of this post.
We are happy to report that zkSync now meets 100% of Reddit’s requirements! 🎉🎊🥳
What is zkSync?
zkSync is a trustless protocol for scaling Ethereum, powered by zkRollup technology. It uses zero-knowledge proofs to bring scale, data availability, and privacy to Ethereum, all without data ever leaving mainnet.
While security and decentralization are Matter Labs’ main priorities, user and developer experience are central to the design of zkSync. We’re obsessing over how to eliminate user friction and complexity from Ethereum. We think that users and buidlers alike will find zkSync the most flexible, yet convenient tool in the Ethereum space.
Some useful links to learn more:
zkSync from the Bake-Off Challenge Perspective
zkSync v1.1 is a zkRollup that can reach a peak capacity of up to 3,000 TPS on today’s Ethereum mainnet. Though it’s unrealistic to expect zkRollup to run on its full speed 100% of the time (since rollups share Eth block space with other transactions), even 25% of block space utilization would be sufficient to support token distribution and subscriptions for all 500,000,000 Reddit users.
3,000 TPS is a start, but we’re expecting Ethereum user growth to give Moore’s Law a run for its money. To prepare Ethereum for billions of users, Matter Labs has presented an extension to zkSync that we’re calling zkPorter. zkPorter will allow protocols to lift themselves into shards with a further 10–100x transaction throughput beyond even zkSync.
zkRollup offers unsurpassable security compared to existing L2 scaling solutions. A simple litmus test: does a protocol X require active work by participants to keep their assets safe? If the answer is yes, then something can always go wrong with the security measures and the funds lost.
zkRollup is, to the best of our knowledge, the only protocol that offers passive security guarantees: data availability is isolated from user activity, ensuring that funds are as secure as the underlying L1.
It’s worth pointing out that zkSync relies on recent cryptography, which introduces protocol risk. Specifically, zkSync v1.1 is powered by PLONK, a universal SNARK, developed in 2019 (aka SNORK). While cryptographic assumptions of this system are widely considered secure, it does require a one-time trusted setup obtained through a multi-party computation ceremony.
To supply a source of entropy for our zkSync production beta, Matter Labs participated in the AZTEC Ignition community trusted setup ceremony. There were over 200 participants in attendance, including representatives from the Ethereum Foundation, Consensys, Vitalik, and others. What a trusted setup means for our users is that if at least a single participant participated honestly in the setup procedure (by supplying entropy in the Common Reference String), the entire network is cryptographically secure in perpetuity. Reddit can be added as a participant to the Ignition setup used by zkSync, providing further security guarantees for the Reddit community.
Perfection is fleeting. zkSync will evolve beyond a trusted setup. That’s why researchers at Matter Labs designed and implemented RedShift: a transparent SNARK. Future versions of zkSync will use RedShift as we expect the performance of RedShift to meet or exceed what’s possible on the PLONK.
zkSync’s protocol, cryptography and smart contracts have been audited by one of the most reputable security companies in the space: ABDK Consulting (founded by co-authors of the Poseidon hash function).
Our mission at Matter Labs is to accelerate the mass adoption of public decentralized blockchains. Freedom and self-sovereignty are the foundational values of our company. We’re here to combat centralized power aggregation, and creeping economic and surveillance controls. And we will not stop until every person in the world has uncompromised, private access to the open, permissionless, and censorship-free global digital economy.
We recognize that trade-offs are inevitable along this way — but we are very careful to pick our trade-offs. The Internet started out as a free and neutral space. In 2020, most of its infrastructure is controlled by a handful of big players. We need to avoid enabling large players to dominate the internet of finance.
zkSync is 100% censorship-resistant at the L1: because data availability is guaranteed at the L1, no validator can ever prevent users from recovering their funds. Because of this, and because L2 is only getting started, we found it acceptable to follow the path of progressive decentralization and initially launch zkSync with permissioned validators. The right to validate blocks is granted by zkSync governance smart contract.
Ultimately, the health of the ecosystem depends on a truly decentralized L2 (accept no substitutes!). Since most transactions will eventually be conducted on the L2, a failure to decentralize permissions to the L2 is a failure to decentralize Ethereum. Matter Labs is committed to making zkSync strongly censorship-resistant at L2. To achieve this, we are building a scalable multi-validator consensus with a separate censorship-prevention mechanism. You can learn more about it in the zkSync vision post.
Usability is where zkSync shines.
Using zkSync with existing wallets is about as simple as it gets. A zkSync transaction requires a single zkSync-specific secret key for signatures. Integrating with zkSync is but a few lines of code for wallet providers.
zkSync finality is tightly coupled to Ethereum finality — users wait minutes at most to see their transactions settle (including exits). zkSync doesn’t rely on liquidity providers to accelerate user exits, and users don’t have to regularly log in to “check on” their funds to keep them secure from malicious exit attempts. Best of all, gas fees on zkSync are ~100x reduced from the L1.
zkSync natively supports meta-transactions: fees can be paid in the same token which is being transferred. In our zkSync v1.1 update, we’ve added the option for 3rd parties to cover transaction costs in any costs. For instance, Reddit could pay for it’s users in ETH, DAI, or any ERC20.
zkSync works with any web3-enabled wallet (e.g. MetaMask or WalletConnect).
The API and SDK for zkSync are open, permissionless and fully documented.
zkSync is interoperable with smart contracts on L1.
With the release of Zinc — a zero-knowledge friendly smart contract programming framework–zkSync will be able to integrate smart contracts directly into the L2.
A great example of how smart contracts can unleash the sheer power of recursive zero-knowledge proofs is voting. A decision involving votes of millions of community members—with voting power tokenized on zkSync—can be verified by a L1 smart contract at the cost of 510,000 gas!
New Features in zkSync v1.1
We’ve added some new gadgets in v1.1. Read on to learn how we’ve increased our transaction volume from 300 to 3,000 with the power of recursion. Or skip ahead to learn more about recurring payments, batch transactions, and minting and burning tokens.
Recursion: up to 3,000 TPS
zkSync v1.0 is powered by PLONK and requires a one-time universal setup. For production, we used the results of the Ignition MPC ceremony with over 200 participants. The size of the setup had to be kept relatively small to make participation practical. Unfortunately, this limited the maximum size of the zk proof for a block, and thus the maximum throughput of zkSync was capped at ~300 TPS.
To lift this limitation, we implemented and fully integrated into zkSync recursive PLONK verification! Up to 20 normal blocks can now be verified by a single aggregating block, and only this last proof needs to be submitted on-chain. The prior block implementation required no modification: it still contains the same audited code.
In our zkSync “Reddit edition” loadtest, only recursive proofs were submitted to the smart contract, reducing the zero-knowledge proof overhead to 40 gas per transfer (a PLONK proof verification costs 510,000 gas in EVM). It is now also trivial to add a meta-block that can verify other aggregating blocks, allowing zkSync to aggregate arbitrarily many blocks into a single proof, reducing the proof overhead to as little as 1 gas per transaction.
Pure data availability cost in zkSync is 320 gas per transfer right now. With further minor changes in our validator node and smart contract to batch the commits together — that were not included in this month’s sprint as it was already incredibly tightly packed—zkSync’s capacity will be scaled up to the maximum limit imposed by Ethereum: 3,000 TPS (assuming 13 seconds Eth block interval and 12,5M block gas limit).
Recurring Payments (Subscriptions)
Convenient subscriptions require recurring payments: a user pre-authorizes the service once to charge a specified amount every month, week, or year, without any further interaction on the user’s part.
To implement recurring payments, we introduced a timestamp variable accessible in zkSync circuits, which mirrors timestamps on Ethereum blocks. Users can authorize transfers executable only within a specific time window.
Every transfer transaction has a fixed nonce to prevent replay attacks. It is impossible to predict what nonce will a user’s account have a month or two from now.
In order to add subscription transactions, a user signs the nonce of the receiving account, rather than the sender account.
We created a demo app and documented a detailed protocol for using zkSync for Reddit subscriptions.
Transaction Batches (3rd-party Fee Coverage)
User experience should be simple and easy. We want zkSync to integrate seamlessly into all pre-existing wallets and payment tools. We’ve made it possible to pay transaction fees in the token being transferred. If a user only owns DAI, it should not be necessary to additionally own ETH to pay the gas fees.
While users can generally pay transaction fees in whatever token they please, there are a couple exceptions. Tokens with insufficient market liquidity (ie. tokens that are relatively uncommon) will have to have their gas fees paid in a token with higher liquidity. Second, when a third party subsidizes the transaction fees for its users, the third party may pay the transaction fees in whatever token(s) it prefers, regardless of the users’ currencies.
To support this feature, we have introduced transaction batches. Transaction batches bundle a set of transactions into a single transaction, with a corresponding reduction in fees paid by the guarantor.. Reddit can use this functionality to pay the transaction fees for the community point transfers.
Minting and Burning Tokens
Reddit’s scaling challenge requirements required that token minting (controlled by a smart contract) and burning be performed as directly possible in L2. Fortunately, zkSync’s flexible architecture made this an easy task.
Every account in zkSync is controlled by the L1 account with the same address. This enables smart contracts to control zkSync accounts! Here is how it works.
zkSync-aware ERC20 token contract
We need a special ERC20 token contract (you will find a template here) that is aware of minting and burning in L2. Here is the code template. In constructor, this contract will register with zkSync to create an account it controls: we will call it a genesis account.
This contract contains the function setMultisigMintingKey(), which can be used anytime to define the M-of-N multisig group key on the genesis account. This group authorizestoken minting inside zkSync. It must be noted that zkSync natively supports multisig functionality on its accounts with a muSig scheme.
The multisig group signs an authorization to mint tokens for a given user. This signature is sent to the user, whereupon the user can call the mint() function from the zkSync SDK to mint new tokens. Those tokens will appear in the user’s account. Authorizations and minting are separate operations and can happen independently without synchronization.
On every withdrawal from zkSync, our special ERC20 token contract increases the totalSupply variable, tracking the total token value in circulation on L1. On every (re-)deposit into zkSync, the totalSupply is decreased.
Burning tokens in L2 is as simple as sending them to an unusable address, such as 0x0000000000000000000000000000000000000000.
Calculating total token supply
The total token value in circulation on L1 is tracked by the public totalSupply variable of the ERC20 token contract.
The total token value in circulation on L2 can be easily calculated by a simple formula:
total = genesis_initial - (genesis_current - burner_current)
- genesis_initial is the initial token balance on the genesis account (a constant defined in the ERC20 token contract),
- genesis_current is the current balance on the genesis account,
- burner_current is the current balance on the burning account (e.g. 0x0000000000000000000000000000000000000000).
zkSync doesn’t have a token yet, and no sale or distribution is planned in the near future. Please beware of scammers.