Incentive Mechanism of Polygon ZK EVM
About how the Polygon ZK EVM functions and the incentive structure contributes to its operation
This project is part of TOKAMAK ZK-EVM. It received a grant from the Ethereum Foundation’s Ecosystem Support Program, as part of the Academic Grants Round 2023. I want to thank Jehyuk Jang, Hyoyeong Kim, Hyesu Im, and Yeongseong Son for their valuable feedback and support.
In this article, we will examine the incentive mechanism of Polygon ZK EVM (formerly Polygon Hermez). This exploration will focus on why the incentive mechanism exists, how it works, and the economic effects it brings in Polygon ZK EVM.
ZK rollup basics
Before we dive into the main discussion, let’s ensure we have a shared understanding of the fundamental concepts: Zero-Knowledge Proofs (ZKP) and ZK Rollup, which are the core technologies behind Polygon ZK EVM.
ZKP
A zero-knowledge proof in cryptography is a method where one person can demonstrate their knowledge of something to another person, providing proof, without revealing the actual content of that knowledge.
Let’s use a simple example to explain. In the scenario pictured above, Alice wants to prove that she knows a passcode without revealing the actual code. She does this by showing that she can reliably reach Bob, no matter which route he tells her to take in response. This not only proves that Alice knows the code but also stops Bob from discovering it.
ZK rollup
A rollup is a layer 2 (L2) technology that makes blockchains faster and cheaper in the following ways:
- It groups several transactions together in a batch and processes them off the main blockchain, which makes them faster and less expensive.
- It verifies and finalizes transactions on established blockchains, like Ethereum, benefiting from their proven security measures.
As you may have guessed, a ZK rollup is a particular type of rollup that employs ZKP. When a batch of transactions is sent to the main blockchain and the L2 state is updated accordingly, you can verify it using a specific proof without revealing all the exact details of the entire batch.
Note: Moving forward, for simplicity’s sake, we’ll refer to ‘rollups’ in this article as those that operate with Ethereum.
ZK rollups can be categorized into different types based on a trade-off between compatibility with the Ethereum Virtual Machine (EVM) and operational performance. When a ZK rollup closely imitates Ethereum, using EVM as-is but sacrificing speed and efficiency, it’s assigned a lower type number, such as Type 1 or Type 2. Conversely, if it prioritizes performance over similarity to Ethereum, it receives a higher type number, such as Type 3 or Type 4.
What is Polygon ZK EVM?
The Polygon ZK EVM is a ZK rollup developed by Polygon, designed to achieve Type 3 equivalence with the EVM. In the long term, the Polygon ZK EVM is working towards achieving Type 2 equivalence and eventually becoming fully equivalent to the EVM.
Working mechanism
Note: In this article, “L2” refers to rollups, while “L1” refers to Ethereum. The term “L2” or rollups can have different meanings depending on the context, including 1) Polygon ZK EVM, 2) Polygon Hermez, or 3) rollups in a broader sense.
In the Polygon ZK EVM, sequencers are responsible for creating L2 transaction batches and sending them to L1. Meanwhile, aggregators generate proofs for these batches and submit them to L1. This is how the Polygon ZK EVM operates, with sequencers and aggregators playing central roles:
- L2 users create, sign, and then send transactions to the Trusted Sequencer’s node, which are stored in the pending transactions pool.
- After verifying signed transactions from the pool, the Trusted Sequencer includes the executed transactions in a transaction batch. These transactions are subsequently shared with other nodes, forming the “Trusted State.”
- The Trusted Sequencer sends the batch to L1, where it is arranged into a sequence. In PolygonZkEVM.sol, only the commitment of this sequence is stored in the sequenced batches repository, creating the “Virtual State.” The data availability of sequenced batches is guaranteed by the calldata of the sequencing transaction.
- Next, the Trusted Aggregator updates the L2 state root and generates the required proofs. These proofs serve not only to ensure the integrity of calculating the new L2 state root but also to verify the consistency of inputs used in this calculation when compared to the batches sequenced by the Trusted Sequencer.
- These components are then sent to the batch execution proof verifier in PolygonZkEVM.sol. If the provided proofs are considered valid, the new L2 state root is confirmed as accurate and stored in the L2 state roots repository within PolygonZkEVM.sol, creating the “Consolidated State.”
Note: In the Polygon ZK EVM, when L2 transaction batches are sent to L1, they aren’t hidden or compressed. Instead, each transaction is encoded or serialized using the RLP (Recursive-length prefix) standard.
Incentive mechanism of Polygon ZK EVM
What is incentive mechanism?
An incentive mechanism is a system that influences how individuals behave by adjusting the rewards and penalties associated with their choices. For example, businesses can encourage employees to increase their productivity by offering higher salaries. Conversely, the legal system can deter individuals from committing crimes by imposing appropriate punishments.
Why incentive mechanism in Polygon ZK EVM?
The Polygon ZK EVM currently relies on the centralized sequencer and aggregator, but it aims to become more decentralized in the long term. However, there’s a challenge. The decentralized system depends on people voluntarily participating, and unless they get some benefits, not many will contribute.
That’s why Polygon ZK EVM needs an incentive mechanism. Specifically, it should be designed so that sequencers and aggregators are properly compensated for their work to make a profit.
Polygon Hermez: PoB (Proof-of-Burn)
Interestingly, the initial incentive mechanism in Polygon ZK EVM was different from what it is today. Its forerunner, Polygon Hermez, employed PoB to ensure smooth operations.
What is PoB?
In PoB, miners earn the privilege of creating blocks by sending coins to an inaccessible address, effectively “burning” them. Typically, the more coins miners burn, the higher their chances of being selected to generate blocks. This coin burning serves as an economic incentive because miners must produce valid blocks and earn transaction fees to offset the costs associated with burning coins.
It’s important to understand that depending on how PoB is used, miners might destroy the native currency of the blockchain or another currency like Bitcoin. For example, in Polygon Hermez, those who want to create L2 transaction batches and proofs burn the native token, HEZ. On the other hand, in Stacks, a Bitcoin layer for decentralized apps and smart contracts, potential miners burn Bitcoin, not STX, the native coin of Stacks.
PoB in Polygon Hermez
In Polygon Hermez, PoB involves an auction. In this auction, individuals called ‘coordinators’ compete to gain the privilege of forming L2 transaction batches and computing proofs. The coordinator who places the highest bid in HEZ, the native token of Polygon Hermez, wins the auction. The winnings are allocated as follows:
- 30% is destroyed (burned).
- 40% goes to a donation account managed by the Ethereum Foundation.
- 30% is kept as incentives to encourage people to use Polygon Hermez, like rewarding transactions or addresses that hold coins or tokens on Polygon Hermez.
Economics of POB in Polygon Hermez
PoB in Polygon Hermez carries significant economic implications.
Unlike PoW (Proof of Work) or PoS (Proof of Stake), where miners or validators receive most of the rewards, PoB aims to distribute value more evenly among a larger community of stakeholders. When tokens are burned, it often raises the token’s value by decreasing the total supply, benefiting all token holders. Additionally, the coins allocated for donations or incentives are crucial for supporting the broader ecosystem.
Furthermore, in PoS, tokens are simply staked, but PoB makes L2 operations more efficient by mandating the use of assets. Only coordinators who can cover big auction bids, as well as the expenses for batch generation and validation, are allowed to take part in Polygon Hermez’s PoB. This typically encourages selected coordinators to include numerous transactions in blocks, leading to swift settlements.
Polygon ZK EVM: PoE (Proof-of-Efficiency)
Why not PoB?
Why did Polygon ZK EVM stop using PoB, despite its positive economic effects?
One key reason is that PoB tends to rely on a monopolized block market, which can lead to operational centralization. In Polygon Hermez, the protocol essentially monopolizes the available block spaces, and coordinators have to compete for them. This situation isn’t great for coordinators because they have to spend a significant amount of coins to be selected. Even if they can afford these costs, they might still lose their investment unless they are the absolute best at what they do. Even a small inefficiency is unacceptable. All of these factors discourage coordinators from participating actively, ultimately resulting in centralization.
Furthermore, this operational centralization exposes users to increased risks of attacks and censorship. In the case of Polygon Hermez, the coordinator who wins the auction gains significant control over the network for a specific duration. This coordinator could decide to reject legitimate transactions or, in extreme cases, take no action at all. If this coordinator is highly efficient or wealthy enough to win consecutive auctions, it could bring Polygon Hermez to a complete standstill.
What is PoE?
PoE was introduced to address the issues with PoB mentioned earlier. PoE involves two main types of participants: sequencers and aggregators. Sequencers create L2 transaction batches and send them to L1, while aggregators generate proofs for these batches and submit them to L1. These proofs are accepted on a first-come, first-served basis.
Importantly, PoE fosters inclusivity by reducing the hurdles to becoming either a sequencer or an aggregator. For instance, if you don’t have a substantial amount of capital to win the ‘burning auction,’ you can become a sequencer by setting aside a specific number of coins to compensate aggregators. Similarly, anyone capable of running the software to calculate the state roots and associated proofs can become an aggregator and receive the coins initially deposited by sequencers.
PoE in Polygon ZK EVM
In Polygon ZK EVM’s PoE, anyone can become a sequencer, making batches of L2 transactions and sending them to the L1 network to earn L2 transaction fees. To encourage aggregators to create proofs and finalize these transaction batches, sequencers must lock a certain number of MATIC coins as batch fees, which depend on the number of batches in the sequence.
Anyone can become an aggregator, producing proofs and submitting them with the latest L2 state root to the L1 network, thus obtaining the MATIC coins locked by the sequencers as aggregation rewards.
Economics of PoE in Polygon ZK EVM
PoE in Polygon ZK EVM aims for different economic goals compared to PoB in Polygon Hermez.
In contrast to PoB in Polygon Hermez, PoE in Polygon ZK EVM rewards those who actively contribute, such as sequencers and aggregators, instead of simply redistributing value to token holders. In simpler terms, it doesn’t take money away from efficient and potentially wealthy entities and give it to regular stakeholders, as we observed in Polygon Hermez.
Furthermore, unlike PoB in Polygon Hermez, PoE in Polygon ZK EVM promotes increased decentralization. This is because PoE fosters a more competitive environment for sequencers and aggregators with lower barriers to entry. For example, even slightly less capable sequencers or aggregators can compete with the most efficient ones by offering slightly lower profit margins.
PoE in Polygon ZK EVM also manages batch fees according to network demand, acting as an automatic stabilizer for the economy.
Batch fees change due to two elements:
- the targeted batch verification time, which is the intended duration for sequenced batches to be verified with proofs, and
- the batch fee multiplier, a specific number used to modify the batch fee, presented as a three-decimal value ranging from 1000 to 1024.
When the late batches (those verified slower than targeted) outnumber the early batches (those verified faster than targeted), the batch fee is modified in the following way:
The aim is to raise the aggregation reward, encouraging aggregators in situations where batch verification takes longer and mirrors a slower network condition.
For instance, if numerous batches miss the intended verification time, it suggests aggregators might be hesitating due to potential insufficient rewards. In response, the batch fee multiplier can be raised by the admin, causing an increase in batch fees. In the formula mentioned earlier, both the base (batch fee multiplier / 1000≥1) and the exponent (late batches count — early batches count) rise, leading to higher batch fees.
When there are more early batches than late ones, the batch fee is adjusted in the following manner:
This seeks to decrease the aggregation reward, helping to calm down an excessively active network situation.
For example, if many batches meet the targeted verification time, it shows that aggregators are happy with rewards and swiftly create proofs for transactions. In this scenario, the admin can increase the batch fee multiplier, resulting in reduced batch fees. In the formula mentioned, the base (1000 / batch fee multiplier ≤ 1) decreases, and the exponent (early batches count — late batches count) rises, resulting in lower batch fees.
QnA
About technicalities of Polygon ZK EVM operation
Q1: Can L2 transactions be verified using matching proofs without revealing the linked information with the current ZKP technology?
A1: Not at the moment. For instance, you can go through all the L2 transaction data on the Polygon ZK EVM explorer (https://zkevm.polygonscan.com/).
Q2: What factors cause Polygon ZK EVM to have Type 3 equivalence instead of Type 2 equivalence?
A2: You can find more information on this website: https://wiki.polygon.technology/docs/zkevm/protocol/evm-diff/.
Q3: When L2 transactions are sent to L1, are there any methods to conceal and condense the associated data?
A3: No, L2 transactions are merely encoded or arranged using RLP (https://wiki.polygon.technology/docs/zkevm/protocol/transaction-batching/). The entire serialized data is transmitted to L1 and serves as a parameter for the batch sequencing process (https://wiki.polygon.technology/docs/zkevm/protocol/transaction-sequencing/).
Q4: Does the proof relate to 1) confirming the batch’s formation validity or 2) confirming the individual L2 transaction’s validity?
A4: The Trusted Sequencer checks if the batch is correctly formed and if each L2 transaction within it is valid. The proofs provided by the Trusted Aggregator serve a dual purpose: not only do they guarantee the accuracy of the newly calculated L2 state root, but they also confirm that the inputs used in this calculation match the batches sequenced by the Trusted Sequencer, ensuring consistency.
Q5: The cost of gas would be very high if the original L2 transaction data is sent to L1.
A5: It’s true that gas costs can be relatively high because L2 transactions, when not condensed, are submitted to L1. However, the original L2 transaction data is saved in calldata, which is much cheaper than using storage. You can find this information in the code, specifically at line number 485 of the file “PolygonZkEVM.sol.”
Q6: What do you mean by “complex off-chain calculations”?
A6: This refers to calculations needed for creating the new L2 state root and its corresponding proofs. Some examples could include polynomial calculations within the Polynomial Commitment Scheme.
About PoB of Polygon Hermez
Q1: Is PoB talked about in connection with L1 or L2? Is PoB required for achieving consensus in L2?
A1: PoB can be used in both L1 and L2. When considering the decentralized operation of L2, it’s important to agree on how to select the entity responsible for creating blocks or batches at regular intervals. PoB could serve as one possible approach for this. As we delve into PoB Economics, it becomes clear that PoB supports a more equitable distribution of value and enhances the efficiency of L2 operations.
Q2: Why does Polygon Hermez’s PoB utilize auctions instead of probabilistic selection?
A2: In the context of PoB for Polygon Hermez, either an auction or probabilistic selection approach can be theoretically adopted. The choice of subcomponents within PoB can be flexible and tailored to specific requirements, apart from the burning of coins or tokens.
Q3: How do token holders contribute to the ecosystem?
A3: Token holders contribute by supporting the stability of the token’s value through holding and not selling their tokens. Additionally, when considering a broader definition of token holders, liquidity providers can also fall into this category.
Q4: An auction-based PoB system might cause users to leave the platform due to higher transaction fees.
A4: Miners (or coordinators) can’t ignore users and dramatically increase transaction fees because fewer users typically mean reduced earnings for them. Given a competitive L2 environment, users have the option to swiftly switch to alternative L2 solutions if transaction fees become unreasonably high. This dynamic prevents miners from excessively taking advantage of users.
About PoE of Polygon ZK EVM
Q1: What are the “distinct costs” for aggregators to create proofs?
A1: These costs refer to the electricity used for running the ZK Prover, an off-chain software that calculates the new L2 state root and generates the corresponding proofs.
Q2: Does PoE resemble PoW in allowing both aggregators and miners to create a pool?
A2: Indeed, in the Polygon ZK EVM’s Proof of Execution (PoE), aggregators can come together to create a pool that speeds up the proof generation process. This is similar to how miners in Proof of Work (PoW) often collaborate to quickly find the right nonce.
Q3: Has Polygon ZK EVM’s PoE been completely set up?
A3: It appears to still be in the development phase as it relies on decentralized sequencers and aggregators, which currently isn’t the case.
Q4: Aggregators seem to have excessive control. How about a system where users select sequencers and sequencers then choose aggregators?
A4: You’re right that aggregators in Polygon ZK EVM’s PoE can hold significant power. One way to address this is through a few “boot aggregators” controlled by the protocol. The alternative system you proposed is certainly more democratic. However, this approach could become inflexible and inefficient because users and sequencers would rely on specific selections of sequencers and aggregators.
Q5: Who has the authority to adjust the batch fee multiplier?
A5: Admin can do it. Admin consists of three developer from the Polygon team. They use a wallet that requires 2 out of 3 of them to agree (Admin Role and Governance | Polygon Wiki).
References
https://vitalik.ca/general/2022/08/04/zkevm.html
https://zkevm.polygon.technology/docs/architecture
https://zkevm.polygon.technology/docs/protocol/protocol-components
https://zkevm.polygon.technology/docs/protocol/state-management
https://zkevm.polygon.technology/docs/category/transaction-life-cycle
https://zkevm.polygon.technology/docs/protocol/incentive-mechanism