Explain the importance of Rollup's decentralization from the perspective of philosophy, technology and economy

Author: Shivanshu Madan

Compilation: Luffy, Foresight News

A lot of the discussion on Crypto Twitter lately revolves around L2 decentralization. Is the Rollup we're building decentralized enough? Are they already on the road to decentralization? Does it matter?

I will explore these themes in this article. Before I dig in, if you don't already know how Rollups really work, I suggest you give this article a quick read: Rollups for Dummies.

The idea of Rollup is actually quite simple: it wants off-chain participants to conduct transactions that can then be easily verified on-chain. With Rollup, the "trust" of the base layer is extended to activities outside its blockchain. In return, Rollup pays a small fee (rent) to use this trust.

So do we need decentralized Rollup?

The intuitive answer is: definitely need to! This is the spirit of blockchain.

However, I also believe that the answer to this question is not a simple yes or no. Rather, it encompasses multiple aspects, which must be analyzed individually. In what follows, I will explore this issue from three perspectives: philosophy, technology, and economics.

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, and it may soon become the global payment currency used by most of the world. That's the power of permissionless innovation!

Blockchain allows us to work with people who have nothing in common and we know there is no way for them to break that trust.

——Preston Evans

The decentralized foundation of trustless networks like Bitcoin and Ethereum allows us to build such a future. Obviously, any chain that has a trust relationship with these blockchains, such as Rollup, 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) permissioned chains, and users of that Rollup would still be able to leverage the underlying layer security. As long as the base layer is decentralized and Rollup is "fully implemented" (we'll talk more about "full implementation" in the technical section), even permissioned chains should be safe to use.

But the reality is that most Rollups today haven't reached the stage of full implementation, and they don't provide users with the level of security and trustlessness they need.

So, what is the correct implementation of Rollup? let's see:

Technical Perspective

To truly understand Rollup's decentralization and security concerns, we need to look at it from first principles. Few people can explain the first principles of blockchain better than Sreeram Kannan.

Blockchain is a distributed ledger, and different nodes in the network follow predetermined protocol rules to obtain a 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 their own ledger network.

Especially in Rollup, full nodes and light clients have different confirmation rules. In the 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 a consensus zone, all participants have the same view of the network (and the same history in the ledger).

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.

• Ledger growth - Rollup chain should keep growing (liveness)
• Censorship resistant - all users should be able to include any transaction into the base layer
• Restructuring resistant - transactions cannot be withdrawn once completed
• Data Availability - transaction data should be published somewhere
• Validity - transactions and state transitions should be valid

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

Let's examine these issues from the perspective of different Rollup participants 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 execute transactions yourself and determine the validity of the transactions and the final state of the Rollup after those transactions.

The remaining safety conditions are therefore activity and recombination resistance. For reorganization resistance, full nodes rely on the base chain's validators and the consensus protocol it uses, while for liveness, full nodes rely on the Sorter and Rollup implementations.

Light client:

Most users interact with the blockchain using light clients to fetch blockchain data. There are several types of light nodes:

• State validators - verify the validity of state transitions
• Data Availability Verifier - Verify data availability
• Consensus validators - verify the consensus proof of the base layer
• Full Validator - Validates all of the above

If you run a full validator light client, you can verify whether data is available through data availability sampling, verify the validity of state transitions through validity proofs or fraud proofs, and verify whether the state follows the consensus of the base layer (in Ethereum above, can be done by following the synchronization committee).

Then the remaining safety condition is liveness, and the light client depends on the Sorter and Rollup implementation.

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
• Builds on previous state for anti-recombination
• Realize data availability by submitting DA at the base layer *Validity verified by proof of validity/fraud

SCR full nodes rely on smart contracts to enforce liveness properties. They get their reorganization 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 proofs of validity by themselves or via smart contracts.

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

**How about Sovereign Rollup? **

Sovereign Rollups do not have smart contracts (validation bridges) to enforce validity or liveness conditions. Instead, they will prove to "roll down" to downstream Rollup nodes. These nodes still rely on data availability and reorganization resistance from the base layer.

As 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 Rollup must include two important components:

• Mandatory inclusion mechanism;
• Sequencer replacement protocol.

Mandatory inclusion mechanisms help increase censorship resistance. This mechanism allows users to "force include" their transactions directly in the base layer. Any user on the Rollup can then force withdraw their funds back to the base layer. Therefore, even if there is only one centralized collator node, it cannot censor users as long as there is a mature mandatory inclusion mechanism.

But is that enough?

Even if users are free to exit, this could mean that L2 doesn't have much incentive to continue operating if most users run back to L1. 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 entirely practical (or real-time), we can call it "weak censorship".

Then we have the final activity attribute - ledger growth.

If the centralized orderer does something evil, it can stop the growth of the Rollup chain by simply stopping block production. If this happens, there is nothing the user can do to make the Rollup "live" again.

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

The idea of the Sequencer Replacement Protocol is that if a Sequencer behaves in a malicious manner, Rollup is able to start a new Sequencer through governance. One of the ways to achieve this is to replace centralized orderer nodes with decentralized orderer protocols. If the orderer is decentralized and does not monopolize Rollup's block building, then it will be nearly impossible to block the Rollup chain.

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 completely. From a technical point of view, there is one more aspect to consider:

What if the smart contracts themselves could be upgraded by Rollup's central committee? Let's say Rollup is 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 disagree with such an upgrade, you should be able to exit Rollup before the upgrade is implemented (although this is not a good user experience and may be bad for the business). This can be achieved through "delayed governance updates", like a "notification period", after which upgrades will be implemented. Users who do not agree to updates can withdraw within the notice period.

The extreme of decentralization is to have 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 the smart contract to be updated, Rollup's only option is to fork to the new smart contract, while user funds are stranded in the old contract.

Unfortunately, the current state of Rollup is nowhere near the full implementation we discussed above. Most Rollups are still in the "exploration" phase, trying to implement them correctly.

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

Economic Perspective

Finally, let's take a look at Rollup economics from the perspective of users and Rollup operators:

• User experience: users should get cheap prices and not have to wait too long for transactions;
• Rollup Profit: Sequencers and token holders should be profitable.

User experience is optimized when users receive fast and cheap transaction services.

The speed at which transactions are finalized depends on the speed at which the base layer is 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 sorter is useful because it can provide users with a "soft confirmation" that their transaction is included in a block and will be finalized. This is sufficient for most use cases. However, it relies on centralized institutions that can take adverse actions.

While some orderer-alternative protocol solutions forego this property (as disadvantageous to users), other solutions, such as the external PoS consensus scheme Espresso, can provide similar pre-confirmation guarantees without the risk of a centralized orderer.

What about user costs?

The explicit cost of a Rollup transaction is usually:

L2 Gas Cost = L1 Gas Cost + Sequencer Fee. Rational centralized sorters always want to maximize their 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 mismatch problem, where Rollup may not want to hand over profits to external sequencers.

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

If Rollup is replaced by an external PoS consensus, they will hand over this MEV to an external operator.

It is worth noting that both of these problems of Rollup handing over revenue to external mechanisms can be solved through "transaction agreements" between Rollup and external mechanisms.

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

This could be a solution that kills two birds with one stone, as it allows Rollup to keep profits in-house, while also mitigating the downside of centralized sorters.

But on the contrary, in the case of limited sequencer rotation, the sequencer can have short-sighted behavior, which may lead to monopoly pricing/price gouging, further harming the interests of sacrificed Rollup users.

Either way, in order for Rollup to be cost-effective for users, some sorter replacement protocol is necessary.

in conclusion

Regardless of the path Rollup takes, it is crucial that it should aim for a complete implementation with a mature sequencer replacement protocol, mandatory inclusion, and lag governance update mechanisms. If there is a mechanism for mandatory inclusion and lagging updates, user funds will be safe whether the sorter is centralized or not.

However, a robust sequencer replacement protocol can improve liveness guarantees and potentially improve economics for Rollup users.