💙 Gate Square #Gate Blue Challenge# 💙
Show your limitless creativity with Gate Blue!
📅 Event Period
August 11 – 20, 2025
🎯 How to Participate
1. Post your original creation (image / video / hand-drawn art / digital work, etc.) on Gate Square, incorporating Gate’s brand blue or the Gate logo.
2. Include the hashtag #Gate Blue Challenge# in your post title or content.
3. Add a short blessing or message for Gate in your content (e.g., “Wishing Gate Exchange continued success — may the blue shine forever!”).
4. Submissions must be original and comply with community guidelines. Plagiarism or re
Talk about the incentive mechanism of Layer 2: another wonderful use of Fiat-Shamir heuristic in FOX
Preface
As a distributed system, Layer 1 requires high communication costs in order to reach consensus, and a large amount of calculations will also consume expensive gas. Therefore, as an extension of Layer1, the design of Layer2 can effectively improve the efficiency of Layer1. But from this perspective, the design of Layer 2 still faces the same big problem as Layer 1, which is how to balance the degree of decentralization and efficiency.
zkRollup is a very promising Layer 2 expansion solution, which is realized by moving calculations off the chain and providing zero-knowledge proofs to the Layer 1 chain. In the solution to realize zkRollup, the FOX system adopts the current mainstream structure, and there are mainly two types of nodes, namely Sequencer and Folder. In simple terms, Sequencer is responsible for sorting and packaging the transactions submitted by users, and updating the status on the Layer2 chain. Folder is responsible for generating proofs for the transactions packaged by Sequencer and submitting them to Layer1.
An interesting question is whether Layer 2 nodes should be decentralized, and if so, how to design incentives to ensure this. Because it is conceivable that the essence of Layer1's low efficiency is that in order to achieve decentralization, each node needs to perform a large amount of calculation and communication. However, the Layer 2 system is used to decouple the calculation process. If the decentralized model that is completely equivalent to Layer 1 is still used in this part, it will cause Layer 2 congestion for the same reason, so a trade-off needs to be made here.
The design of the incentive mechanism is to encourage nodes to participate in Layer2 system maintenance by adjusting the way Layer2 nodes obtain incentive fees and balancing the fees paid to Layer2 nodes. In essence, the source of incentive fees received by Layer2 nodes is the same as that of Ethereum, which comes from the gas fees paid by users who submit transactions. This article will discuss in the FOX system, how FOX nodes participate in the system to collect transaction fees, and the reasons for doing so.
The role of Gas
First, let's review the role of Gas fees in the Ethereum system. The computing resources of Layer1 are limited. When users submit a transaction, they will specify the transaction gas fee. The gas fee is basically related to the complexity of the execution operation of the transaction. On this basis, users who are willing to pay a higher gas fee can get a higher priority transaction implement. The miners' incentives come from the sum of the gas fees of the packaged blocks. In addition, the Gas fee mechanism can also effectively prevent malicious contracts (such as infinite loops) and limit the block size, which guarantees security to a certain extent.
Therefore, it can be seen that the reasonable use of Gas fees is essentially a reasonable scheduling and allocation of computing resources on the chain, and it is also a multi-party game between project parties, miners and users. A good design of the incentive mechanism and the use and distribution of fees are critical to the operation of the system.
Transaction on-chain process
When a user submits a transaction to the transaction pool in the FOX system, a fee is added to motivate the FOX node, and then the Sequencer node in the system will grab the transaction from the transaction pool for packaging and sorting, where each packaged transaction constitutes Layer 2 blocks, and Sequencer needs to perform transaction calculations and transmit the calculation results to the Layer 1 FOX contract, and Sequencer also needs to store transaction data in ZK-Ringer to ensure data availability. Afterwards, the sorting results and calculation results of the Sequencer will be sent to the Folder node, and the Folder will correctly calculate the proof (including the proof aggregation part) and pass it to the Layer1 contract. In this process, the execution result of the transaction by Sequencer will be directly updated to Layer 2 after the execution is completed, and the time node when the transaction is actually consensused by Layer 1 can be regarded as after the Folder's proof is verified.
It can be seen that in this process, the initial handling fee attached by the user covers several purposes:
To this end, we need to sort out specific mechanisms to motivate all parties to participate.
Incentive Mechanism of FOX
FOX's incentive model is relatively new. First, in order to balance the issues of decentralization and efficiency, we divide the roles of nodes into Sequencer nodes responsible for sorting and executing transactions, and Folder nodes responsible for generating and aggregating proofs of transaction execution correctness. FOX's Folder node adopts a decentralized model, which means that any FOX miner can access the network as a proof generator. In order to encourage more nodes to participate, the Folder that successfully submits the correct proof to the Layer1 contract can get token rewards . At the same time, in order to avoid wasting computing power, we point out that not only the first proof submitter can get rewards, but within a time window and quantity window after the first proof submitter successfully submits (the specific parameters here will vary with system conditions), all correct certifiers can be rewarded.
Figure 1: The original version of the incentive model
However, under this mechanism, a malicious Folder will have a very cunning attack.
When a malicious Folder, denoted as Adv, completes proof generation, it submits the proof to the Verifier contract in Layer1 for verification on the one hand, and on the other hand it colludes with some nodes (or nodes controlled by the Folder), and will The calculated proof is disclosed to these nodes, and then they can directly submit the proof calculated by Adv without their own calculation, and can also receive a part of the reward, and they have not paid any computing power during this process. From another perspective In other words, Adv obtains multiple benefits with less computing power, and makes it difficult for other nodes to compete for Adv even if they generate correct proofs.
Figure 2: Attack method of malicious Folder
In this attack, the reason for the problem is that Verifier cannot distinguish whether each certificate is independently generated by the Folder, because the certificate value is the same. In order to avoid this problem, we need to add the unique address information of the Folder to the certificate submitted by the Folder, so that the certificate submitted by each Folder can only be independently generated by itself and cannot be submitted by other nodes.
The method of incorporating this information is very clever, using Fiat-Shamir heuristic (readers can refer to FOX's previous article "How to transform interactive proofs into non-interactive proofs? Fiat-Shamir Heuristic!" for technical details). Calculated according to the process of generating a proof, one of the steps, the prover, that is, Folder needs to generate a random challenge value through a hash function, and only needs to add the address of Folder to the input of this hash, so that the challenge value and Folder corresponding to the address, and is still a random number that Folder cannot predict and control.
Strictly stating the security of this method requires the use of the concepts of theoretically secure random functions in cryptography and indistinguishability, etc., which we will not discuss in detail here. In simple terms, it can be considered that due to the security of the hash function itself and the security of the Fiat-Shamir heuristic structure, adding a fixed value as the preimage of the hash will not destroy the unpredictability of the output, so the original zkp algorithm security is still guaranteed.
In this way, each Folder must independently generate proofs and cannot directly use the results of other nodes, thus achieving our goal.
Figure 3: Modified incentive schema
Conclusion
From the perspective of the important role of node fees, this article introduces the connection between fees and how to motivate nodes to participate in system maintenance. At the same time, it points out that a good incentive mechanism can effectively maintain system security. On this basis, we discussed in detail the incentive mechanism for Layer 2 Folder adopted by FOX, and explained the rationality of this approach, and how to skillfully use Fiat-Shamir heuristic to achieve this.
references
"In-Depth|Iteration and Competition - The Road to Layer 2 Expansion of Ethereum" Guosheng Blockchain Research Institute