View the importance of Rollup decentralization from three aspects

Author: Shivanshu Madan; Compiler: Huohuo/Vernacular Blockchain

A lot of the discussion on Twitter lately revolves around L2 decentralization. Are the Rollups we are building decentralized enough? Or are they at least on the path to decentralization? Does it matter?

The idea of Rollup is simple: we want off-chain participants to be able to conduct transactions that can then be easily verified on-chain. With Rollup, the base layer allows its base of "trust" to be used for activities that occur outside of its immediate sphere. In return, Rollup pays a small fee (rent) to leverage this trust.

So do we need decentralized Rollups?

The intuitive answer is yes! This is the spirit in which we build the blockchain.

However, I believe the answer to this question is not a simple yes or no. Instead, it has multiple facets that must be analyzed individually. In the following chapters, I will break down this question from three perspectives: philosophical, technological, and economic. ****These three are not necessarily exhaustive or exclusive, but they should give a good overall perspective of the problem. **

1. Philosophical perspective

Let's start by taking the conversation up a level - why do we care about decentralization?

Because we want a permissionless future that promotes open innovation. We want users to be able to build new things without any restrictions and without needing to trust any single entity.

In the short history of blockchain, we've had a lot of anonymous developers build amazing things. In fact, Bitcoin itself was created by an anonymous entity - it may soon be the currency most people in the world use for global payments! That's the power of permissionless innovation!

Blockchain allows us to collaborate with people who have nothing in common and we know they have no way to break that trust - Preston Evans

The decentralized foundation of trustless networks like Bitcoin and Ethereum allows us to build such a future. Then it is obvious that any chain that has a trust relationship with these chains, such as Rollups, should also be decentralized!

In fact, it raises an interesting and important question:

**If Rollup is not decentralized, does that mean Ethereum is not decentralized? **

A slightly optimistic way of looking at this is that in a permissionless world, rollups should be allowed to build anything they want, including (but not limited to) fully permissioned chains - and users of that rollup should still be able to Leverage security at the base layer. Even permissioned chains should be safe to use as long as the base layer is decentralized and rollup is "fully" implemented (we'll talk more about "fully implemented" in the technical section).

But the reality is that most rollups today have not yet reached the stage of full implementation, and they do not provide users with the desired level of security and trustlessness.

So, what does the correct implementation of rollup look like? let's see:

2. Technology

To truly understand the issue of decentralization and security at the Rollup level, we need to look at it from first principles. Not many people can explain the first principles of blockchain better than Sreeram Kannan.

A blockchain is a distributed ledger where different nodes in the network follow a defined protocol to gain consensus on the state of the ledger. Depending on how these nodes see the network, they can have different rules for confirming the correct state of the network in their own ledger.

For example, in Ethereum's Gasper protocol, there are two different confirmation rules - the available rule (based on the heaviest chain) and the final rule (based on blocks confirmed by the gadget).

Especially in rollups, full nodes have different confirmation rules than light clients. In traditional smart contract rollup (SCR), the smart contract (verification bridge) has its own confirmation rules. If there are no adverse events, these confirmation rules eventually coincide in so-called "consistency regions". As the name implies, in consensus zones, all participants have the same view of the network (and have the same history in their ledgers).

If all confirmation rules are safe, no bad things will happen. As Sreeram shared in the above post, 5 properties mainly define the security of these confirmation rules.

1. Ledger growth - Rollup chain should keep growing (liveness)
2. Censorship Resistance - All users should be able to include any and all transactions into the base layer
3. Restructuring resistance - transaction should not be reinstated once completed
4. Data Availability - Transaction data should be published somewhere
5. Validity - transactions and state transitions should be valid

The first 2 properties together define the "live" condition of the system, while the last 3 properties define the "safe" condition.

Let’s look at each from the perspective of different aggregation actors and see which ones can be mitigated without decentralization.

Different actors rely on different mechanisms for safety and liveness

Full node:

If you run a full node, you have access to published data and can verify it directly. You can then use that data to perform transactions yourself and determine the validity of transactions and the final state of the Rollup after those transactions.

The remaining safety conditions are thus activity properties and recombination resistance. For the latter, full nodes rely on the validators of the underlying chain and the consensus protocol they use, while for liveness properties, full nodes rely on the sequencer and Rollup implementations.

Light client:

Most users use wallets embedded in light nodes or use third-party services to obtain blockchain data and interact with the blockchain. Light nodes can be of various types:

• State Validator - Verify the validity of state transitions,
• DA Validator - Validates data availability,
• **consensus validator - validating the consensus proof of the base layer, or **
• full verifier - verifies all of the above

If you run a full-validator light client, you can verify that data is available through data availability sampling, you can verify the validity of state transitions through validity proofs or fraud proofs, you can also verify that the state has been finalized on the base Layer consensus (on Ethereum, this can be done by following a sync committee).

The remaining safety condition is then the liveness property, and light clients rely on the sequencer and rollup implementations.

Built-in smart contract (verification bridge):

In traditional SCR, the "confirmation rule" of a smart contract is to enforce all 5 security properties:

• Ledger growth through the sequencer replacement protocol
• Resist censorship by enforcing inclusion
• Build resistance to reorganization only on top of previous state
• Data availability is achieved by submitting DA at the base layer
• Verification of validity via proof of validity/fraud

SCR's full nodes rely on smart contracts to enforce liveness properties. They "absorb" restructuring resistance from the base layer.

Light nodes rely on smart contracts to enhance liveness properties and absorb DA and reorganization resistance from the base layer. They can verify the proof of validity themselves or via smart contracts.

The consensus of SCR is to follow the canonical chain defined by the smart contract.

**What about Sovereign Rollup? **

Sovereign Rollups have no smart contracts (verification bridges) to enforce validity or liveness conditions. Instead, they will prove to "roll down" to a downstream rollup node. These nodes still absorb DA and Reorg resistance from the base layer.

Just like in SCR, in sovereign rollup nodes need some mechanism to enforce the liveness property. To define the canonical chain, they opted for independent mechanisms such as broadcasting p2p proofs.

What does all this have to do with decentralization?

Whether it is a smart contract rollup or a sovereign rollup, the liveness property comes from the correct implementation of the rollup. As we have seen above, a correct implementation of aggregation must include two important components:

1. mandatory inclusion mechanisms, and

2. Sequencer replacement protocol

Mandatory inclusion helps build censorship resistance. This mechanism allows users to "force include" their transactions directly in the base layer. Any user in the rollup can then force exit back to the base layer with their funds. Therefore, even if there is only one centralized collator node for aggregation, it cannot censor users as long as there is a mature enforcement mechanism in place.

But is that enough?

Even if users can log out, this may mean that if most users run back to L1, the enterprise does not have much incentive to continue running. Also, the mandatory inclusion mechanism usually has a long wait time and can be quite expensive to implement for the average user. The censorship resistance provided by this mechanism is not exactly practical (or real-time). We can call this situation "weak censorship".

Then we have the final liveness attribute - ledger growth

If the centralized collator becomes malicious, it can stop the growth of the summary chain by simply stopping block production. If this happens, there is nothing the user or business can do to make the rollup "live" again.

To solve this problem, we need a sequencer replacement protocol.

The idea of the sequencer replacement protocol is that if the sequencer behaves in a malicious manner, the aggregate governance can start the sequencer. One of the ways to achieve this is to replace centralized sequencer nodes with a decentralized sequencer protocol. If the sorter is decentralized and does not monopolize the building blocks of the rollup, it is nearly impossible to stop the rollup.

Thus, while user funds are always safe in Rollups via the mandatory inclusion mechanism, building a robust orderer replacement protocol helps keep Rollups alive and provides practical, real-time censorship resistance.

this is all?

Not quite. From a technical point of view, there is one more aspect to consider:

What if smart contracts themselves could be upgraded by an aggregated central committee? Let's say rollups are currently implemented correctly, but tomorrow the committee agrees that we no longer need smart contracts, but instead broadcast proofs of the rollup state to the p2p network.

If, as a rollup user, you do not agree to such an upgrade, you should be able to exit rollup before the upgrade is implemented (although again, this is not a good user experience and may be bad for the business). This can be achieved through "lagged governance updates". It's like a "notification period" after which the upgrade will be implemented. Users who do not agree to updates can withdraw within the notice period.

The extreme of decentralization is the option of having completely immutable smart contracts. These contracts are not governed by any multi-signature wallet or other committee, and once deployed they can never be upgraded.

Of course, this has its own problems. If there are any bugs in the code, or some major event requires updating the smart contract, the only option for the aggregation node is to fork to the new smart contract - leaving user funds stranded in the old contract.

current status

Unfortunately, the current state of Rollup is nowhere near the full implementation we discussed above. Most rollups are still in the "training wheels" phase, trying to get it right.

According to L2BEAT, Fuel v1 and DeGate are the only two aggregates that have matured to achieve all activity and safety conditions.

3. Economy

Let's look at Rollup economics from the perspective of users and Rollup operators:

1) User Experience - Users should get cheap prices and not have to wait too long for transactions

2) Rollup Profit - It should be profitable for sorters and Token holders to operate Rollup

User experience is optimized when users get fast and cheap transactions.

The speed at which transactions are finalized depends on the speed at which base layer blocks are finalized. Transactions can be considered final whenever data on L1 is finalized. However, users running full nodes can also achieve instant finality by simply executing transactions and determining the final state.

But it's not practical for everyone to run a full node. Therefore, a centralized collator is useful because it can provide users with "soft confirmation" that their transaction is included in a block and will be finalized. This is sufficient for most use cases. However, it involves a reliance on a central party that can act against it.

While some sequencer alternative protocol solutions (e.g. based on Rollups) forego this property to the detriment of users, other solutions (e.g. external POS consensus (e.g. Espresso)) can provide similar pre-confirmation guarantees without incurring the following Risk: Centralized sequencers.

What about the cost to the user?

The explicit price of a Rollup transaction is usually:

L2 Gas Cost = L1 Gas Cost + Sequencer Fee

A central orderer acting rationally always wants to maximize its own profits, even if it means passing higher costs on to users. However, it is worth noting that this cannot necessarily be solved by a decentralized sorter mechanism either. Even POS nodes in a decentralized orderer want to maximize their own profits.

In fact, this creates a misalignment problem where the aggregate may not want to hand over the profit to an external sorter.

Rollup Profit - In addition to sequencer fees, Rollup can also earn profit by extracting MEV from bulk user transactions. This MEV is often hard to attribute because it is hard to find out if the orderer included some of its own front-running transactions in the batch.

**If Rollup is replaced by external POS consensus, they will give this MEV to external operators. **

It is worth noting that both of these problems of Rollups handing over revenue to external mechanisms can be resolved through “trade agreements” between Rollups and external mechanisms, in which fees and MEV generated by internal and cross-Rollup transactions can be resolved. Redirects back to summary.

However, as explained in Jon Charbonneau's talk during the Modular Summit and subsequent posts, a better idea might be to have rollup governance delegate ordering to a set of permissioned nodes. These nodes can be strategically chosen to be geographically dispersed, and governance can simply kick out bad actors.

**This can be a two-bird-one-stone solution, as it allows rollups to keep the margins in-house, while also mitigating the adverse effects of centralized sorters. **

But the opposite of this is that with limited rotation of sorters, sorters can have non-myopic behavior, which can lead to monopoly pricing/price gouging at the expense of aggregation users.

Either way, it's clear that some sequencer replacement protocol is necessary in order for summarization to be cost-effective for users. Whether it is a proof of governance, an external consensus mechanism, or something else, is a discussion for another article.

4 Conclusion

Hopefully it's now clear that whatever path Rollup takes, it's crucial that the goal should be a full implementation with mature mechanisms for sorter replacement, forced inclusion, and lag governance updates. Even if it's just mandatory inclusion and lagging updates, user funds are safe when Rollup is fully implemented, regardless of whether the coordinator is centralized.

However, a robust sequencer replacement protocol could improve liveness guarantees and potentially improve the economics of Rollup users.