https://blog.matter-labs.io/zkporter-composable-scalability-in-l2-beyond-zkrollup-2a30c4d69a75
We present zkPorter: a new L2 scaling technique combining zkRollup and sharding in a highly scalable yet atomically composable blockchain network.
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.
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.
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 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!
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.
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.
https://miro.medium.com/max/1400/0*bBnPWocqKYUQdX7-
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.
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:
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.
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:
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.
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:
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.
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.
zkPorter will be gradually implemented as a part of the zkSync roadmap.
The next steps to accomplish this vision are:
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.
zkSync doesn’t have a token yet, and no sale or distribution is planned in the near future. Please beware scammers.
我们介绍了 zkPorter：一种在高度可扩展但原子可组合的区块链网络中结合 zkRollup 和分片的新 L2 扩展技术。
吞吐量以网络处理的总交易量来衡量。可扩展性是单个节点处理的事务量。zkRollup 可以说是安全性和可用性方面的终极 L2 扩展解决方案。然而，与主网相比，zkRollup 仅提供了约 100 倍的可扩展性提升，因为交易数据仍必须传播到所有完整节点。可以说 zkRollup线性增加吞吐量，但无法提供指数可扩展性。
zkRollup 可以在 Eth1 上处理高达 3,000 TPS，保守地说——取决于 Eth2 的实现细节——在分片的 Eth2 上至少可以处理 20k TPS。这已经是一项巨大的成就，可与Visa 高达 24k TPS 的容量相媲美，但由于我们渴望容纳目前不受当今银行基础设施支持的数十亿人，我们正在努力争取更多。
DeFi 的惊人崛起表明可组合性是成功的关键。可组合的“金钱乐高积木”，DeFi 应用程序展示了通过将去信任协议相互叠加来解锁的潜在价值。将自己限制在自己的扩展解决方案中的项目将发现自己与社区共享、可组合扩展机制的安全和网络效应隔离开来。
在这篇文章中，我们将介绍一种基于 zk 扩展的新方法，它有可能解决上述两个问题：zkPorter。
zkPorter 是一个基于账户的、无需信任的扩展协议，由简洁的零知识证明保护。与 zk 系列中的其他扩展技术（例如 zkRollup 和 Validium）类似，zkPorter 中的计算以指数方式扩展：可以以大致恒定的成本验证任意多笔交易。每笔交易都将通过 L1 上的智能合约进行验证，因此 zkPorter 中帐户状态的正确性与 L1 具有相同的安全保证。
另一方面，基于 zk 的扩容不能直接解决的是数据可用性问题：如果状态数据不可用，资金就会被冻结。zkRollup 和 Validium以不同的方式处理数据可用性问题。
zkPorter 通过结合 zkRollup 和分片思想的混合方法来处理数据可用性。它可以支持任意多个分片，每个分片都有自己的数据可用性策略，由分片的智能合约定义。分片的选择在个人帐户级别进行控制。
zkPorter 将状态有效性和数据可用性的关注点分开。状态有效性——从一个状态到下一个状态的转换总是有效的——通过零知识证明统一执行，它提供指数可扩展性，同时继承底层 L1 的安全保证。相比之下，数据可用性被委托给各个分片，这些分片可以自由地尝试不同的解决方案。在 necessariis unitas 中，在 dubiis libertas 中！
同步跨分片（或跨区块链）互操作性被认为是极其困难的。这就是为什么大多数现有的分片解决方案（Cosmos、Polkadot、Eth2）通过交易收据选择更简单的异步互操作性。从同步互操作性到异步互操作性的转变将在协议互操作性和用户体验方面产生重大问题，特别是对于那些相对时间敏感的问题（例如，Aave 的 15 秒闪贷）。
输入 zkPorter！zkPorter 中的所有帐户共享相同的地址空间，并且可以通过在 zkPorter 的基本分片 shard 0 中运行的 zkRollup 彼此无缝互操作。具有大流量和/或特定数据可用性需求的协议可以将其协议接口提升到自己的分片中zk波特。下一节将讨论将协议提升到自己的分片中所涉及的安全性、成本和吞吐量权衡。
zkPorter 实现了任意多个协议的平滑互操作性。单个原子交易可以在不同的 zkPorter 分片上调用任意数量的智能合约。此外，分片内交易将可以访问整个 zkPorter 状态——包括任何其他分片中的数据。例如，这可以用于读取 oracle 提要。
您可以将 zkPorter 模型视为 zk 类固醇上的区块链互联网。
zkPorter 的 Shard 0 是一个简单的 zkRollup，具有底层以太坊 L1 的完整数据可用性和安全保证。Shard 0 将是 zkPorter 内部运行成本最高的分片，大约是在主网上交易成本的 1/100。
分片 0 以外的分片在自己的智能合约上定义自己的数据可用性策略。zkPorter 的分片交换链上数据可用性，使交易成本进一步降低 10-100 倍，吞吐量增加超过基础分片。zkPorter 引入了一种可选的验证器机制，我们称之为“zkPorter Guardians”，这将使协议能够邀请协议利益相关者作为协议分片上的数据可用性保证人参与。启用 Guardians 的分片将运行某种形式的权益证明共识，其中分片的用户可以选择带着他们的数据退出，只要至少 1/3 的参与验证者保持诚实。
协议可以自由地实施自己的数据可用性策略，包括或排除 zkPorter Guardians。协议选择的数据可用性策略的效率将影响吞吐量和交易成本值。
https://miro.medium.com/max/1400/0*bBnPWocqKYUQdX7-
灵活的数据可用性是 zkPorter 的核心设计目标。通过允许协议设计他们自己的策略，zkPorter 支持广泛的可能的解决方案，以适合每一个。安全假设允许受信任的中心化方作为担保人的应用程序可以实现权威证明共识。具有治理令牌的应用程序可以选择实施自己的权益证明共识以保护其分片——但必须避免允许分片存款量超过质押量。纠删码机制可用于证明验证者不删除。鉴于比特币网络的相对简单性和低交易量，zkPorter 分片的验证者甚至可以在其分片中创建比特币的实现，在基于 Nakamoto Proof of Work 的共识上运行。所有这些都可以与 zkPorter Guardians 验证器设置合并或独立运行。
zkPorter 在设计时考虑了规模。zkPorter 协议将数据可用性和正确性的证明减少到每个分片上的少量开销。提升新分片的边际成本与将嵌套数据包含在基础 zkRollup 中的成本成对数。这将使 zkPorter 能够有效地扩展以支持数亿个帐户。
最后，用户隐私伴随着零知识领域。使用 zkRollup 作为 L2 的基本元素的内在优势是可以证明状态转换的有效性，而无需透露这些交易的内容。
在底层，zkPorter 类似于 zkRollup 和 Validium。L1 上的合约持有一些资金和账户状态的 Merkle 根记录。实际的状态数据由 zkPorter 验证器和每个分片的数据保持器在链下维护：我们将其称为状态树。
分片的智能合约定义了自己的规则，用于何时接受 zkPorter 块。当区块被接受时，该区块会进行状态转换：L1 上的交易将 Merkle 根替换为新值。该交易必须验证新值有效的零知识证明：即区块中的每笔交易都是有效的。
在 zkPorter 中，每个分片的帐户必须存储在状态树的单独子树中。此外，每个分片子树必须包含有关其类型的信息以及对定义其数据可用性策略的智能合约帐户的引用。
如果分片类型是 zkRollup，那么任何修改该分片中账户的交易都必须包含必须作为 L1 调用数据（与 zkRollup 相同）发布的状态更改。
任何修改至少两个不同分片中账户的交易都必须在 zkRollup 模式下执行。
所有其他仅在特定分片的帐户上操作的交易都可以在正常分片模式下执行（我们将它们称为分片交易）。如果一个块包含一个分片S的一些分片交易，那么必须遵守以下规则：