zkPorter: Composable Scalability in L2 Beyond zkRollup
1 billion blockchain users—a scaling architecture proposal
TLDR
We present zkPorter: a new L2 scaling technique combining zkRollup and sharding in a highly scalable yet atomically composable blockchain network.
Problem #1: Throughput ≠ Scalability ⚖️
Throughput is measured in the total transaction volume processed by the network. Scalability is the volume of transactions processed by a single node. zkRollup is arguably the ultimate L2 scaling solution with regards to security and usability. However, zkRollup only offers a ~100x scalability increase compared to mainnet, because transaction data must still be propagated to all full nodes. One could say that zkRollup linearly increases throughput, but offers no way for exponential scalability.
zkRollup can handle up to 3,000 TPS on Eth1, and conservatively — dependent on Eth2 implementation details — at least 20k TPS on a sharded Eth2. This is already a tremendous accomplishment, comparable to Visa’s capacity of up to 24k TPS, but as we aspire to accommodate the billions who are currently unsupported by today’s banking infrastructure, we’re striving for more.
Problem #2: Scalability in Isolation is a Dead-end 🛑
The spectacular rise of DeFi shows that composability is key to success. Composable “money legos”, DeFi applications demonstrate the potential value to be unlocked by layering trustless protocols atop one another. Projects that restrict themselves to their own scaling solutions will find themselves isolated from the safety and network effects of community-shared, composable scaling mechanisms.
Introducing zkPorter 🎉
In this post, we’re presenting a new approach to zk-based scaling that has the potential to solve both of the problems described above: zkPorter.
zkPorter in a Nutshell 🥜
zkPorter is an account-based, trustless scaling protocol secured by succinct zero-knowledge proofs. Similar to other scaling techniques in the zk-family (such as zkRollup and Validium), computation in zkPorter scales exponentially: arbitrarily many transactions can be verified at a roughly constant cost. Every single transaction will be validated by a smart contract on L1, so correctness of account state in zkPorter has the same security guarantees as the L1.
On the other hand, zk-based scaling cannot directly solve is the data availability problem: if the state data becomes unavailable, funds are frozen. zkRollup and Validium handle the data availability problem in different ways.
zkPorter tackles data availability with a hybrid approach that combines the ideas of zkRollup and sharding. It can support arbitrarily many shards, each with its own data availability policy, defined by the shard’s smart contract. The choice of the shard is controlled at individual account level.
zkPorter separates the concerns of state validity and data availability. State validity — that the transition from one state to the next is always valid — is uniformly enforced by means of zero-knowledge proofs, which offer exponential scalability while inheriting the security guarantees of the underlying L1. In contrast, data availability is delegated to individual shards, which are free to experiment with different solutions. In necessariis unitas, in dubiis libertas!
Composability in zkPorter: Internet of Blockchains on Steroids💊
Synchronous cross-shard (or cross-blockchain) interoperability is considered extremely difficult. This is why most existing sharding solutions (Cosmos, Polkadot, Eth2) opt for the simpler asynchronous interoperability, via transaction receipts. The transition from synchronous to asynchronous interoperability will create major headaches around protocol interoperability and user experience, especially for those that are relatively time sensitive (ie. Aave’s 15 second flash loans).
Enter zkPorter! All accounts in zkPorter share the same address space and can seamlessly interoperate with one another through the zkRollup running in zkPorter’s base shard, shard 0. A protocol with heavy traffic and/or specific data availability needs can lift its protocol interface into its own shard of zkPorter. The security, cost, and throughput tradeoffs involved in lifting a protocol into its own shard are discussed in the next section.
zkPorter enables the smooth interoperability of arbitrarily many protocols. A single atomic transaction can invoke any number of smart contracts on different zkPorter shards. Moreover, intra-shard transactions will have access to the entire zkPorter state — including data in any other shard. This can be used, for example, to read an oracle feed.
You can think of the zkPorter model as an internet of blockchains on zk steroids.
zkPorter Shards: Security and Costs 💸
Shard 0 of zkPorter is a simple zkRollup, with the full data availability and security guarantees of the underlying Ethereum L1. Shard 0 will be the most expensive shard to operate on inside zkPorter, about 1/100th the cost to transact on mainnet.
Shards beyond shard 0 define their own data availability policies on their own smart contract. Shards of zkPorter exchange on-chain data availability for a further 10–100x transaction cost reduction and throughput increase beyond the base shard. zkPorter introduces an optional validator mechanism that we’re calling “zkPorter Guardians,” which will enable protocols to invite protocol stakeholders to participate as data availability guarantors on the protocol’s shard. A Guardians-enabled shard will run a form of Proof of Stake consensus, wherein users of the shard will have the option to exit with their data, so long as at least 1/3 of participating validators remain honest.
Protocols are free to implement their own data availability policies incorporating or excluding zkPorter Guardians. The efficiency of a protocol’s chosen data availability policy will affect throughput and transaction cost values.
Flexible data availability is a core design goal for zkPorter. By allowing protocols to design their own policies, zkPorter enables a broad range of possible solutions, as befits each. Applications whose security assumptions admit trusted centralized parties as guarantors can implement Proof of Authority consensus. Applications with governance tokens may elect to implement their own Proof of Stake consensus to secure their shard — but would have to avoid allowing shard deposit volume exceed staked volume. An erasure coding mechanism could be used to prove non-deletion by validators. Given the relative simplicity and low transaction volume of the Bitcoin network, validators of a zkPorter shard could even create an implementation of Bitcoin within their shard, running on Nakamoto Proof of Work based consensus. All of these can be incorporated with, or run independently of a zkPorter Guardians validator setup.
zkPorter is designed with scale in mind. The zkPorter protocol reduces proofs of data availability and correctness to a small overhead on each shard. The marginal cost of lifting new shards is logarithmic in the cost to include nested data in the base zkRollup. This will allow zkPorter to efficiently scale to support hundreds of millions of accounts.
Finally, user privacy comes with the zero-knowledge territory. Inherent in the advantages of using a zkRollup for the base element of the L2 is that the validity of state transitions can be proved, without revealing the content of these transactions.
Architecture 🏛
Under the hood, zkPorter is similar to zkRollup and Validium. A contract on L1 holds some funds and a record of the Merkle root of the account state. The actual state data is maintained offchain by zkPorter validators and data keepers for each shard: we will call it the state tree.
A shard’s smart contract defines its own rules for when a zkPorter block is accepted. When the block is accepted, the block enacts a state transition: a transaction on L1 that replaces the Merkle root with the new value. This transaction must verify a zero- knowledge proof that the new value is valid: i.e. that each of the transactions in the block was valid.
In zkPorter, the accounts of each shard must be stored in a separate subtree of the state tree. Additionally, each of the shard subtrees must contain information about its type and a reference to the smart contract account that defines its data availability policy.
If a shard type is zkRollup, then any transaction that modifies an account in this shard must contain the changes in the state that must be published as L1 calldata (same as a zkRollup).
Any transaction that modifies accounts in at least two different shards must be executed in zkRollup mode.
All other transactions that operate exclusively on the accounts of a specific shard can be executed in normal shard mode (we will call them shard transactions). If a block contains some shard transactions for a shard S, then the following rules must be observed:
- The root hash of the subtree of the shard S must be published once, as calldata on L1. This guarantees that users of all other shards will be able to reconstruct their part of the state.
- The smart contract of the data availability policy of this shard must be invoked to enforce additional requirements (e.g. verify the signature of the majority of the shard consensus participants).
Case Studies 💼
We’d like to present four case studies demonstrating the potential of zkPorter to compose seamlessly with other applications while scaling transaction volume to the needs of each application.
Case-study 1: Reddit community points
In June 2020, Reddit launched The Great Reddit Scaling Bake-Off, an opportunity for communities to own part of their subreddit with a community point system, and for L2 solutions to demonstrate their capacity to meet the requirements. Namely, any solution to the community point system would need to be secure, decentralized, and easy to use, while maintaining interoperability with other third party apps (wallets, contracts), and of course, handle hundreds of thousands of transactions. Community points can be implemented using zkPorter in three different ways.
Option 1: Operate on zkSync (zkPorter shard 0)
To bring community points onto the Ethereum mainnet, Reddit might simply integrate with existing zkRollup functionality on zkSync. As detailed above, zkSync has the capacity for 3,000 TPS on Eth1. Suppose all 500 million monthly active Reddit users actively participate. Assuming 1 minting tx, 1 burning tx (subscription payment) and 2 transfers per month on average, community points will require an average load of:
500,000,000 * 4 / (30 * 24 * 60 * 60) ~ 700 TPS (transactions per second).
This would occupy ~1/4th of the total present capacity of zkRollup (3,000 TPS).
Option 2: Lift into a Reddit-specific shard, validated by zkPorter Guardians
To increase feasible transaction bandwidth while decreasing cost to users, Reddit can lift Reddit transactions off of the base shard into a Reddit-specific shard for its users. Reddit has choices as to how it would like to provide data-availability guarantees to its users. Simplest would be to leverage the existing zkSync Guardians implementation, providing Proof of Stake data availability guarantees for users. We would suggest that Reddit expand the Guardians template to additionally host data on Reddit’s servers. In this model, even a two-thirds attack by Guardians would be circumventable by Reddit, thereby providing strong data availability guarantees for Reddit users. Likewise, users’ data would be protected from a Reddit server failure, attacks by hackers, etc.
Option 3: Lift into a Reddit-specific shard, with a Reddit-specific data availability policy
Third, Reddit could elect to maximize transaction throughput while minimizing costs by lifting the Reddit community into a Reddit-specific shard with a custom data availability policy, sans zkPorter Guardians. A possible scheme, based on Proof of Stake consensus, might rely on community-driven data availability, as above, combined with a two-thirds multisignature.
In one possible scheme implementation, Reddit and Reddit’s users would submit signatures attesting to each state transition’s validity. Reddit might, for instance, possess one third of the total signature weight, while distributing the remaining two thirds to users. A combined two thirds in signature weight would be sufficient to permit a state transition on the Reddit shard. If a user were to identify an invalid state transition, the user might be incentivized to publish a proof of the invalid transition, thereby slashing the stake of the invalid state transition publisher.
Transaction costs in the proposed scheme would only cover zk proof generation (USD ~$0.001 per tx right now, expected to plunge by orders of magnitude in the near future).
Interoperability
In any of these scenarios, Reddit community point holders would be able to:
- Easily interact with smart contracts on other shards, for example trading/lending/borrowing using DeFi protocols deployed on zkSync (Curve on zkSync, Compound on zkSync, etc.)
- Move their community points to an account on a zkRollup shard for maximum security
- Quickly withdraw their tokens to the Ethereum mainnet to interact with non-zkSync smart contracts
Case-study 2: Smart wallets / crypto banks (Argent, Dharma, MyKey, etc.)
Smart wallets are wallets integrated with a smart contract, which can handle privacy and interoperability functions for users (for instance, seamlessly integrating the wallet with L2 scaling). Some wallets, like Argent, even opt to pay a portion of user gas fees while onboarding new users. At the present gas price, 75 Gwei, and Eth price, $320, that’s 50 cents per simple transaction. A smart wallet could integrate their smart contract to call a zkRollup function to reduce their total gas cost.
Here’s a possible implementation, in three simple steps.
Step 1: zkRollup shard
Smart wallet accounts can be moved to a zkRollup solution like zkSync today. Transactions between wallets inside zkSync are cheap, while transactions from zkSync to mainnet will be slightly more expensive and will take longer (~5–10 minutes to finality).
Step 2: zkSync Guardians + Wallet operator shard
After onboarding an army of new users, the cost to operate a zkRollup may spur a wallet operator to consider opening their own shard. Above in the Reddit section, we detailed what this would look like: moving their user base to a separate shard where data availability is secured by zkSync Guardians (Reddit’s community members, possibly protocol politicians here) plus the wallet operator. A shard remains secure so long as either the wallet operator or zkSync guardian majority remains uncompromised. This option also opens a way for organic fee sharing with the wallet operator.
Step 3: Wallet DAO shard
At some point, the user base might become so massive that the wallet might decide to migrate to a shard governed by governance token holders This shard would remain part of zkSync network and would have access to services in all other shards in zkRollup mode.
Privacy considerations
It should further be noted that privacy could easily be implemented at any of the 3 steps described above. Privacy is not easy to implement without integrating without zero knowledge proofs. The beauty of a zkRollup is that accounts simultaneously have access to privacy, and dramatically lower the cost to participate on the network, without sacrificing on security or decentralization.
Case-study 3: DeFi protocols and DEXs (Loopring, IDEX, Curve, Compound, etc.)
Forseeing the scaling bottleneck, several major DeFi protocols (such as IDEX or Loopring) invested into deploying their own scalability solutions. This was a smart move, as it gave them a competitive edge in the age of surging gas prices on the one hand, and a deeper understanding of scaling technology/trade-offs on the other hand.
Moreover, for DEXes striving to enable high-frequency trading, the price of a single transaction must be kept at absolute minimum, because closing an order requires a high number of transactions.
However, two issues crystalize out of this approach:
- Isolated scalability solutions are suffering from the lack of composability and network effects.
- As the full potential of zero-knowledge proofs unfolds, more and more people recognize that ZKPs are the key to real mass adoption. At the same time, the speed of innovation in the ZKP space is so fast that keeping up with it requires its own dedicated R&D team. Failure to properly audit and implement complex cryptographic algorithms opens potentially devastating security vulnerabilities. The golden rule of cryptography rings true: don’t roll your own crypto.
zkPorter solves these problems. DeFi protocols can build on the state-of-the-art scaling technology with strong network effects, while keeping the transaction costs in check. To achieve this, a protocol can create its own shard in zkPorter, secured by the consensus of protocol token holders. This will also provide an organic opportunity for fee-sharing or fee subsidies.
Case-study 4: Microtransactions (Brave, Livepeer, Storj, etc.)
Protocols that need to perform a large number of low-value transfers (microtransactions) might implement a Validium-like shard (i.e. a shard where data availability is protected by a simple multisig of multiple validators), keeping the transaction costs at the bare minimum to cover ZK proof generation (USD ~0.001 per tx right now, expected to plunge by orders of magnitude in the near future).
Integration with a microtransaction platform could include an option for users to automatically transfer their balance onto a zkRollup shard on a recurring basis, or after the balance exceeds some amount.
The Path Forward 🛣
zkPorter will be gradually implemented as a part of the zkSync roadmap.
The next steps to accomplish this vision are:
- Bringing generic smart-contract support to zkSync.
- Implementing a multi-validator consensus mechanism.
- Distributing zkSync tokens to fuel the Guardians shard.
zkSync is live on Ethereum mainnet and can be used right now in permissionless zkRollup mode. We believe that its throughput capacity will be sufficient to cover the scaling needs of the Ethereum community for the next 2 years, while the network transitions to Ethereum 2.0. However, we are open to discussing and implementing custom shard solutions sooner for a promising partnership.
Please get in touch.
Concluding note
zkSync doesn’t have a token yet, and no sale or distribution is planned in the near future. Please beware scammers.