Learn about the new consensus mechanism PoE developed by the Polygon team for zkEVM
Author: David Schwartz, Head of the Polygon Hermez Project; with Developer Jordi Baylina
Compiled by: Babbit
Our Polygon Hermez team is currently working on the implementation of zkEVM, and this challenge requires us to research and develop a new consensus mechanism for decentralized L2 protocols—proof of efficiency (PoE).
This consensus mechanism leverages the experience of the existing Proof-of-Donation (PoD) in v1.0, aiming to build the first decentralized zk-rollup and support permissionless participation from multiple coordinators for batch production in L2.
We are still considering several options and improving this protocol for v2.0 (zkEVM), but we are excited to share our thoughts with the community and receive feedback.
Background
The challenge of decentralization in zk-rollups is significant, and so far, it has been difficult to find a good solution. This occurs because protocols like PoS have some issues on L2, and it is necessary to generate zk validity proofs with high performance (which is very computationally intensive for provers) so that the network can maintain its service levels. Assigning the right to generate a batch (L2 block) to any random validator does not guarantee this.
Proof-of-Donation/Burning Proof (PoD/PoB) is based on a decentralized auction model to obtain the rights to produce batches within a specific time frame. In this case, economic incentives are set up so that validators need to be very efficient to be competitive, representing a significant advancement.
One issue with this model is that the network can be controlled by a malicious single participant within a specific timeframe, making it difficult to avoid zero impact on service levels, especially during the bootstrapping phase, even if there are ways to mitigate the effects.
On the other hand, auction protocols are very costly and complex for coordinators/validators, and only the most efficient will be rewarded. They are difficult to automate, and the complexity of forecasting is high, as auctions require bidding in advance.
Another issue with previous protocols is the effectiveness of converging on the "winner-takes-all" model of the "best" operator. This does not allow slightly underperforming operators to compete. As a result, the operators controlling the network become very centralized due to the censorship resistance limitations arising from this situation.
New Requirements
This new protocol aims to cover the key properties required for such L2 zk-rollup consensus models:
- Permissionless access to produce L2 batches
- Efficiency is key to network performance
- Avoid control by any single party
- Prevent malicious attacks
- Total validation workload proportional to the value in the network
Proof of Efficiency (PoE) Model
This batch creation protocol consists of a two-step model that splits activities between different parties. The first party involved is the Sequencer, and the second party is the Aggregator.
Sequencers
In this model, Sequencers are the parties that collect L2 transactions from users, thus selecting and preprocessing new L2 batches in the network by sending L1 transactions that contain all selected L2 TX data. Anyone can become a Sequencer; this is a permissionless role consisting of gateways to the network.
Interestingly, these proposed batches will be recorded in L1 transactions of the zk-rollup model (or recorded in different data availability networks in the case of Validium).
This batch proposal occurs when they decide to do so based on the incentives they possess:
- One potential is the economic value of transactions in their funding pool.
- Or they need to meet the service levels for users (fees may vary accordingly, as they will be required by Sequencers).
To propose a new batch to the network, Sequencers will need to pay the gas fees of the L1 network to generate a transaction containing all batch transaction data, and the protocol defines the additional fees that need to be deposited in $MATIC tokens. This way, Sequencers are incentivized to propose valid batches with effective transactions.
Batch fees will vary based on network load, calculated according to parameters automatically invoked by the protocol smart contract.
These batches, in the format of L1 transactions, with information in CALLDATA, will serve as data availability for the L2 network, and any new permissionless node will be able to synchronize the state and also reconstruct from that information.
Once mined, these data availability L1 transactions define the L2 TXs to be executed and their specific order. This creates a deterministic new state that can be computed by network nodes as a virtual future state.
Of course, this new state will be resolved when the validity proof of the new state (ZKP) is generated and mined in L1. This corresponds to the second part of the protocol.
Aggregators
Of course, one of the main advantages of zk-rollups is the rapid certainty of transactions provided by validity proofs. The protocol attempts to enhance the validity of these proofs.
Aggregators are the parties that participate in the proof of efficiency consensus protocol in a permissionless manner.
In this mechanism, the right to create validity proofs for the new L2 state (of course, charging a portion of the fees in txs) is obtained simply by being the first Aggregator.
It works as follows: Batches proposed by Sequencers in L1 are sorted according to their appearance in L1 and contain transaction data. The PoE smart contract will accept the first validity proof that updates to the new valid state, including one or more proposed batches.
Aggregators need to define their goals to trigger proof generation and compete based on their own strategies.
For example, if there is a batch containing a small number of TXs, some Aggregators may find it uninteresting to generate a proof and create a state change containing N proposed batches before generating proof with more value. Other Aggregators may have different strategies.
For Aggregators that are late to the competition, if the proof sent does not propose a new state, the smart contract will execute using Revert and check with the Merkle tree hash of the entire state database. Therefore, not being the first comes at the cost of generating proof, but most of the gas fees are recovered.
Of course, the proof will only exist if Aggregators correctly handle the proposed batches, meaning they have an order and all need to be processed. This is a mechanism similar to the "Force tx" implemented in Polygon Hermez v1.0, which helps avoid censorship.
This mechanism avoids control by a single party and many potential attacks, as any Sequencer can propose a batch, but this comes at a cost. Aggregators can also choose to participate in a permissionless manner, but if they do not, sooner or later, someone interested in the economic value will do so.
In our case, the Polygon Hermez network will initiate a bootstrapping of Aggregators to support a specific frequency of new validity proofs during the bootstrapping phase.
Fees will be distributed as follows:
- Fees from L2 TXs will be handled and distributed by the same aggregator that creates the validity proof.
- All TX fees will be sent to the corresponding Sequencer for each batch.
- Fees deposited by Sequencers for creating batches will be sent to the aggregator, which will include that batch in the validity proof.
Conclusion
The PoE consensus mechanism aims to address some challenges of decentralization and permissionless validators in zk-rollups on L2.
It defines a two-step model that supports:
- Permissionless Sequencers as participants in the protocol who benefit and are also a source of network scalability.
- A data availability model that is perfectly compatible with Volition (zk-rollup and Validium) modes, enabling different service layers for users.
- The calculation of "virtual" states from data availability and validity proof-based "final" states. This architecture can save significant costs for decentralized zk-rollups by setting the frequency of validity proofs based on different criteria, but it is not the only solution for confirming transactions.
- Permissionless Aggregators as agents performing specialized tasks for generating cryptographic proofs, which are expected to be costly for the zkEVM protocol. It provides them with a very simple and direct model to manage their incentives and rewards.
- Native protection against L2 network issues: for example, attacks from malicious actors or technical problems with selected validators.
- Incentive model: to maximize the performance of network finality.