Understanding Decentralized Rollups in One Article

Original title: "Decentralized Rollups"

As the use of Rollups increases and hosts the ecosystem's applications, migration costs for users will increase, and centralized orderers will gain monopolistic influence over pricing. Controllers of centralized orderers are justified in maximizing value extraction (MEV) from users both directly (e.g. through fees) and indirectly (e.g. through frontrunning transactions, sandwich attacks, etc.). — Espresso

As mentioned by the Espresso team, centralized Rollups will eventually face monopoly pricing and MEV issues. Additionally, centralized Rollups inherently break composability, leading to fragmented Rollups. **

However, almost all current Rollups are still centralized, because building a decentralized, permissionless and scalable Rollup is extremely challenging. Another reason is that launching centralized Rollups first can help incubate the ecosystem and grab market share.

And when we discuss decentralized Rollups, especially zkRollups, there are two levels of decentralization. The first is the decentralization of the prover, and the second is the decentralization of the orderer. To achieve complete decentralization, it is also necessary to solve the coordination problem between the orderer and the prover.

Under the trend of modularization, there are currently three main types of participants in decentralized Rollup. The first category aims to achieve fully decentralized Rollups and proposes a complete solution. The second category is protocols designed to solve prover networks. Finally, there are multiple solutions that are working to decentralize the sorter.

Rollups decentralized

In zkRollups, Polygon and Starknet have come up with solutions to decentralize their Rollups.

Polygon

Before the introduction of POE (Proof of Efficiency), Polygon zkEVM adopted POD (Proof of Donation), enabling the sorter to bid for the opportunity to create the next transaction batch. However, this creates the problem that a single malicious party can control the entire network by bidding the highest.

After adopting POE, the orderer and prover will participate in the permissionless network most efficiently under their own hardware conditions. Anyone can join the Polygon zkEVM as long as it makes economic sense.

In Polygon zkEVM, the sorter requires 16GB of RAM and a 4-core CPU, while the prover requires 1TB of RAM and a 128-core CPU. In addition, there is a role called an aggregator, which is responsible for collecting L1 data, sending it to the prover, receiving the proof and submitting it to L1. We can regard the aggregator and the prover as the same subject, because the relationship between the aggregator and the prover is very simple, and the aggregator pays the prover to produce the proof.

This architecture is very simple: any orderer can package transactions based on the previous state on L1 without permission, and update the corresponding state. At the same time, any aggregator can submit a proof to verify the updated state.

In POE, efficiency refers not only to the network efficiency of participants competing with each other, but also to the economic efficiency of the sequencer and prover themselves. In L2, the orderer and the prover share the transaction fee, and the orderer pays the batchFee to the aggregator to generate the proof. This ensures that participants are economically motivated to contribute to network efficiency, resulting in a more robust and sustainable ecosystem.

sorter

  • Income: L2 transaction fees
  • Cost: batchFee (calculated in $MATIC) + L1 transaction fee (call sequenceBatches method)

Aggregator (Prover)

  • Income: batchFee (calculated in $MATIC)
  • Cost: proof cost + L1 transaction fee (call verifyBatchesTrustedAggregator method)

Coordinator: batchFee

  • initial parameter
  • batchFee= 1 $MATIC
  • veryBatchTimeTarget = 30 minutes. This is the target time for the validation batch. The protocol will update the batchFee variable to achieve this target time.
  • multiplierBatchFee = 1002. This is the batch fee multiplier, ranging from 1000 to 1024, with 3 decimal places.
  • Regulator
  • diffBatches : the number of aggregated batches > 30 minutes minus the number of batches <= 30 minutes. The maximum value is 12.
  • Coordination process
  • Increase aggregation reward to incentivize aggregators when diffBatches > 0.

  • When diffBatches < 0, reduce the aggregation reward to suppress the aggregator and slow down the aggregation process.

Starknet

Starknet also aims to build a fast-confirmation permissionless and scalable Rollup. While the final specification for the decentralized solution has yet to be reached, they published some drafts on the forum a few months ago.

Compared with the simple mechanism of Polygon zkEVM, Starknet's scheme is more complicated because it includes L2 consensus and chained proof-of-a-protocol in the proof network.

sorter

Instead of simply adding a consensus layer within the orderer layer, Starknet proposes a dual ledger consensus protocol. In this protocol, L2 provides fast response as a live protocol, while L1 checkpoints provide final confirmation as a safe protocol.

For L2's live protocol, various consensus mechanisms can be adopted, such as Sybil-resistant PoS systems such as Tendermint or DAGs. On the other hand, L1's safe protocol involves multiple contracts that handle Stake management, proof verification, and status update respectively.

The typical workflow of the dual ledger consensus protocol is as follows:

  1. First, use the output of the L2 live ledger as the input of the L1 safe ledger to generate a checked live ledger.

  2. Then, take the checked live ledger as input and input it again into the pure consensus protocol of L2 to ensure that the checked live ledger is always the prefix of the live ledger.

  3. Repeat the above process.

When building a dual-ledger consensus protocol, there is a trade-off between cost and latency. The ideal solution aims to achieve both low cost and fast final approval.

In order to reduce gas costs on L2, Starknet divides checkpoints into "minute level" and "hour level". For "minute-level" checkpoints, only the state itself is committed to the chain, while the rest of the data (validity proofs, data availability, etc.) is sent over the StarkNet L2 network. These data are stored and verified by StarkNet full nodes. On the other hand, "hourly" checkpoints are publicly validated at L1. Both types of checkpoints provide the same final confirmation. For "minute-level" checkpoints, the validity proof is verified by StarkNet full nodes, and can be issued by any node on L1 to give L1 finality to "minute-level" checkpoints. Therefore, the prover needs to generate small proofs to be widely disseminated in the L2 network.

To further reduce latency, Starknet proposes a leader election protocol to determine the leader in advance. The basic logic is as follows: the leader of the current epoch i is pre-determined based on the amount of L1 staked and some randomness. Specifically, in epoch i-2, the leader_election method tiles the sorters lexicographically based on the amount of pledges in epoch i-3. Then, send a transaction to update the nonce and pick a point at random. The sorter corresponding to the position where the point falls will be the leader of epoch i.

Certifier

Under the POE module, there is an open competition among participants, which can lead to a winner-takes-all situation. Starknet tries to achieve a competition mechanism without centralization risk. Here are a few options:

  • Rotation: This can partly solve the centralization problem, but may not provide incentives to find the best person to prove the work.
  • Stake-based: The sorter determines the probability of being elected as a prover based on the amount it stakes.
  • Commit-Reveal scheme: The first committer needs to pledge tokens to obtain a short monopoly opportunity, and then generate proofs within this time window. In order to avoid DDoS attacks, if the former cannot generate proofs in time, the collateral tokens required by the latter will increase exponentially. Although under this mechanism, the network may lose the machine with the best performance, but more provers can be cultivated.

In addition to competition among provers, the barrier to entry should be lowered so that more provers can participate in the network. Starknet proposes a complex protocol utilizing recursive proofs called chained protocol proofs.

In proof-of-chain protocols, the blockchain itself is divided into several different forks. This way proofs can not only be recursive, but proof generation can also be concurrent. For example, in a 3-branch setting, 12 black blocks are divided into 3 rows, each row representing a branch. We can think of each branch as a sub-chain where each block should attest to the previous block. From the point of view of the whole chain, slot n needs to prove slot n-3. The interval of 3 blocks allows enough time for the orderer to calculate and purchase proofs in advance. This is somewhat similar to sharding, where an attacker only needs to control one branch to control the entire network of provers.

In order to weave these branches together, Starknet proposes a weaving technology that can merge multiple nodes together to jointly verify the legitimacy of transactions and ensure the consistency and reliability of transaction records.

One solution is to require that each slot needs to be merged with several branches at the same time. Another solution is to alternately try each branch to merge with other branches, thereby reducing the workload of proof. Of course, this is also an open problem, and there may be better solutions in the future.

coordination

In order to actively ensure that the prover can have enough profit space, Starknet proposes a method of referring to the EIP1559 scheme: set the base fee as the lower limit of the prover's resource price, actively conduct price discovery, and the sorter can use tips to motivate the prover . This way, the prover will always be overpaid, and only extreme cases will affect the proof process. Otherwise, if the prover gets paid close to the market price, a slight fluctuation could trigger a prover lockout.

Certifier Decentralization

From the perspective of Rollups, the prover is easier to achieve decentralization than the sorter. Also, the current prover is a performance bottleneck and needs to keep up with the batching speed of the sorter. When the decentralization of the sorter has not been resolved, the decentralized prover can also provide services for the centralized sorter.

In fact, not only Rollups, zkBridge and zkOracle also need a prover network. They all require a strong distributed network of provers.

In the long run, a prover network that can accommodate different computing power is more sustainable, otherwise the best performing machines will monopolize the market.

Proof Market

Some protocols do not coordinate the relationship between the sequencer and the prover, but directly abstract the coordination into a proof market. In this market, proofs are commodities, provers are producers of proofs, and protocols are consumers of proofs. Market equilibrium is most efficient under the influence of the "invisible hand".

Mine

Mina has established a proof marketplace called Snarketplace where Snark proofs are traded. The smallest unit here is the Snark proof of a single transaction. Mina employs a recursive proof of state tree called Scan State.

Scan State is a forest of binary trees where each transaction is a node. A single proof is generated at the top of the tree that can prove all transactions in the tree. The prover has two tasks: the first is to generate proofs, and the second is to merge proofs.

After the prover completes the work and submits the bid, the block producer of the Mina protocol will select the bidder with the lowest price. This is also the equilibrium price, as bidders will submit bids above the cost of proofs, and block producers will not buy proofs that are not worth the money.

=Nil; Foundation

Mina's proof market is designed for its own protocol, while =nil; Foundation proposes a general proof market to serve the entire market.

The market service consists of three components: DROP DATABASE, zkLLVM and Proof Market.

  • DROP DATABASE: It is a database management system protocol, which can be regarded as a DA layer.
  • Proof Market: is an application that runs on DROP DATABASE, similar to what some call a zk-proof "decentralized exchange".
  • zkLLVM: is a compiler that converts high-level programming languages into inputs for provable computing protocols.

Each proof consists of its different inputs and circuits, so each proof is unique. A circuit defines a type of proof, similar to how a "transaction pair" is defined in financial terms. Additionally, different proof systems introduce more circuitry.

The workflow is as follows: the demand side of the proof can write code in a high-level programming language, then feed it to =nil; zkLLVM through the toolchain, generating a single circuit that will become a unique trading pair in the market.

For the proving demand side, they can make a trade-off between cost and time. Provers will also consider their computing power and income. Therefore, in the market, there will be different computing power, high computing power will generate proofs faster, but at a higher cost, while low computing power will generate proofs slower, but cheaper.

TWO-STEP COMMIT

Recently, Opside proposed a two-step commit scheme to decentralize the prover network. The scheme divides the proof submission into two phases to avoid the situation where the fastest prover always wins.

  • Step 1: Submit the hash of the zero-knowledge proof of the T-th block
  • Starting from block T+11, new provers are no longer allowed to submit hashes.
  • Step 2: Submit a zero-knowledge proof
  • After the T+11th block, any prover can submit a zero-knowledge proof. If at least one zero-knowledge proof passes verification, it will be used to verify all submitted hashes, and the verified prover will receive corresponding PoW rewards in proportion to the mortgage amount.
  • If no zero-knowledge proof is verified before the T+20th block, all provers who submitted hashes will be penalized. Then reopen the sorter, you can submit a new hash, go back to step 1.

This method can accommodate different computing power. However, the required collateral still introduces a level of centralization.

Sorter Decentralization

Decentralization of orderers is more complex than that of validators. This is because the sorter has the power to package and arrange transactions, and issues such as MEV and income distribution need to be considered.

Given that Ethereum will prioritize liveness over responsiveness, L2 solutions should complement this trade-off by prioritizing responsiveness over liveness. However, compared to centralized sorters, decentralized sorters inherently sacrifice in terms of responsiveness. Therefore, various optimizations need to be implemented to solve this dilemma.

Currently, there are three different decentralized sorter proposals. The first solution is realized by optimizing the consensus mechanism. The second scheme involves a network of shared sequencers. The third scheme is based on L1 validators.

consensus

The consensus protocol is primarily responsible for ordering transactions and ensuring their availability, not executing them. However, directly adding another consensus layer, as mentioned earlier, is not an easy solution.

To improve responsiveness, a common approach is to rely on a smaller set of validators. For example, Algorand and Polkadot use randomly sampled smaller committees to batch transactions. All nodes use random beacons and a verifiable random function (VRF), with a probability of being included in a committee in a given period proportional to their staked amount.

To reduce network traffic, smaller Data Availability (DA) committees can be used. Or use VID (Verifiable Information Dispersal). VID distributes the erasure code of the data to all nodes participating in the consensus, so that any subset of nodes holding a sufficiently high pledge ratio can cooperate to restore the data. The trade-off of this approach is to reduce broadcast complexity, but increase the complexity of data recovery.

Arbitrum selected reputable entities to form the validator set, such as ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, IFF's Distributed Ledger Research Center (DLRC), and Unit 410 to join the Sorter Committee. The trade-off in this approach is to make up for the lack of quantity by improving the quality of decentralization.

Shared Sequencer Network

Sorters play a vital role in modular blockchains, especially in Rollups. Each Rollup typically builds its own network of sorters. However, this approach not only creates redundancy problems but also hinders composability. To solve this problem, some protocols propose to build a shared Rollup sorter network. This approach reduces the complexity of achieving atomicity, composability, and interoperability, features that users and developers desperately need in open, permissionless blockchains. Additionally, it also eliminates the need for a separate light client for the orderer network.

Astria

Astria is developing a middleware blockchain for Celestia's Rollup ecosystem, which includes its own collection of distributed orderers. This set of orderers is responsible for accepting transactions from multiple Rollups and writing them to the base layer without executing them.

The role of Astria is mainly focused on transaction ordering and operates independently of the base layer and Rollup. Transaction data is stored on the base layer (e.g. Celestia), while Rollup full nodes maintain state and execute operations. This ensures that Astria is decoupled from Rollup.

For finality, Astria provides two levels of Commitment:

  • "Soft commitment": Enables Rollup to provide fast block confirmations to its end users.
  • “Firm commitment”: The speed is the same as the base layer, ensuring higher security and finality.

Espresso

Espresso has made a significant contribution in the field of zero-knowledge technology. Their latest development is a comprehensive solution for decentralized sorters that can be applied to Optimistic Rollups and zkRollups.

The decentralized orderer network consists of:

  • HotShot Consensus: Prioritize high throughput and fast finality over dynamic availability.
  • Espresso DA: Combining committee-based DA solution and VID, where high-bandwidth nodes feed data to all other nodes. The availability of each individual block is also supported by a small randomly elected committee. VIDs provide a reliable but slower backup, guaranteeing availability as long as a sufficiently high percentage of staked weight of all nodes is not compromised.
  • Rollup REST API: Ethereum compatible with JSON-RPC.
  • Sequencer contract: verify the HotShot consensus (that is, act as a light client) and record checkpoints (that is, make a cryptographic commitment to the transaction), and manage HotShot's pledge table.
  • P2P network: Gossip protocol.

Compared to Astria, Espresso offers DA. Therefore, the workflow will be slightly different, as follows:

  1. The user creates and submits a transaction to Rollup.

  2. The transaction is propagated through the orderer network and retained in the mempool.

  3. Designate a leader through the HotShot pledge mechanism, propose a block, and propagate it back to Rollup's executors and provers.

  4. The leader sends the transaction to the Data Availability Committee and receives a DA certificate as feedback.

  5. The leader also sends a commitment to the block to the Layer 1 Sorter contract, along with the certificate the contract uses to validate the block.

Espresso introduces the Gossip protocol for proofs to provide a more flexible user experience. It provides three options for transaction finality:

  • Fast: Users can trust the Rollup server that has executed the transaction and generated the proof, or they can take advantage of HotShot's low latency to execute the transaction.
  • Moderate: The user can wait a while for the proof to be generated, then check it.
  • Slow: Users can wait for L1 verified state updates to get the updated state without any trust assumptions or calculations.

In addition to the above optimizations, Espresso also plans to have the entire Ethereum validator set itself participate in running the Espresso orderer protocol. Using the same set of validators will provide similar security, and sharing value with L1 validators will be more secure. In addition, Espresso can also take advantage of the ETH re-staking solution provided by EigenLayer.

Radius

Radius is building a trustless shared ordering layer based on zero-knowledge proofs, focusing on solving the MEV problem in L2, because L2's revenue mainly comes from block space. The tradeoff to consider is the balance between MEV and L2 revenue. The goal of Radius is to eliminate MEV, which is harmful to users, and proposes a two-layer service.

The top layer targets regular user transactions and provides cryptographic protection against unwanted MEV through the use of timelock puzzles. Specifically, it employs Practical Verifiable Delayed Encryption (PVDE) technology, which will generate zero-knowledge proofs for RSA-based timelock puzzles in 5 seconds. This method provides a practical solution to protect users from harmful MEVs. In short, the transaction content cannot be known until the sequencer determines the order of transactions.

The underlying layer is designed for block builders and allows them to participate in revenue-generating activities while mitigating the negative impact of MEV.

Based Rollups

Based Rollup is a concept recently proposed by Justin Drake, where L1 block proposers cooperate with L1 searchers and builders to include rollup blocks in the next L1 block without permission. It can be viewed as a network of shared sequencers on L1. The advantages and disadvantages of Based Rollup are obvious.

On the positive side, Based Rollup takes advantage of the liveness and decentralization provided by L1, and its implementation is simple and efficient. Based Rollup is also economically consistent with L1. However, this does not mean that Based Rollup compromises its sovereignty. Although MEV is handed over to L1, Based Rollup can still own governance tokens and charge base fees. Based on the hypothesis, Based Rollup can take advantage of these advantages, achieve dominance, and ultimately maximize returns.

in conclusion

Looking at the proposals proposed, it can be seen that Rollup's decentralization still has a long way to go. Some of these proposals are still in draft stage and require further discussion, while others have only completed preliminary specifications. All of these scenarios need to be implemented and rigorously tested.

While some Rollups may not explicitly propose a corresponding decentralized solution, they often include escape mechanisms to address single points of failure due to centralized orderers. For example, zkSync provides a FullExit method that allows users to withdraw their funds directly from L1. When the system enters exodus mode and cannot process new blocks, the user can initiate a withdrawal operation.

To achieve censorship resistance, these Rollups often also allow users to submit transactions directly on L1. For example, zkSync employs a priority queue for such transactions sent on L1. Similarly, Polygon zkEVM includes a force batch method in the L1 contract. When no aggregation occurs within a week, the user can call this method on L1 and provide the transaction's byte array and bathFee to the prover.

What is certain is that in the foreseeable future, Rollup's decentralization will be a combined solution, which may include the above-mentioned important solutions or some other innovative variants.

View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
  • Reward
  • Comment
  • Share
Comment
0/400
No comments