Original Author: Shivanshu Madan

Original compilation: Luffy, Foresight News

A lot of the discussion on Crypto Twitter lately revolves around L2 decentralization. Is the Rollup were building decentralized enough? Are they already on the road to decentralization? Does this still matter?

I will explore these themes in this article. Before I dig in, if you dont 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 to the next 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, weve 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. Thats 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. It is obvious that 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 more optimistic way of looking at this is that in a permissionless world, Rollups should be allowed to build whatever they want, including (but not limited to) permissioned chains, and users of that Rollup would still be able to take advantage of the base layer security. As long as the base layer is decentralized and Rollup is fully implemented (well talk more about full implementation in the technical section), even permissioned chains should be safe to use.

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

So, what is the correct implementation of Rollup? lets see:

technical perspective

To truly understand Rollups 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 traditional smart contract rollup (SCR), the smart contract (verification bridge) has its own confirmation rules. If there are no adverse events, these validation rules will eventually coincide in what is called the consistency zone. As the name suggests, 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 resistance - all users should be able to include any transaction into the base layer

• Restructuring resistant - transactions cannot be reversed 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 look at 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 security and activity

Full node:

If you run a full node, you have access to published data and can verify it directly. You can then use this data to execute transactions yourself and determine the validity of the transactions and the final status of the rollup after these transactions.

The remaining safety conditions are therefore activity and resistance to recombination. For reorganization resistance, full nodes rely on the validators of the underlying chain and the consensus protocol it uses, while for liveness, full nodes rely on the sequencer and Rollup implementation.

Light client:

Most users use light clients to obtain blockchain data to interact with the blockchain. There are many types of light nodes:

• State validators - verify the validity of state transitions

• Data Availability Validator - Validates data availability

• Consensus Validators - Proof of consensus validating the base layer

• Full Validator - Validates 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, and you can verify that states follow the consensus of the base layer (in Ethereum above, can be done by following the synchronization committee).

Then the remaining security condition is liveness, and the light client relies on the sequencer and Rollup implementation.

Built-in smart contract (validation bridge):

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

• Ledger growth via sequencer replacement protocol

• Resist censorship by enforcing inclusion

• Build on previous state to resist recombination

• Achieve data availability by submitting DA at the base layer

• Verify validity via validity/fraud proof

SCR full nodes rely on smart contracts to enforce liveness properties. They gain resistance to recombination 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.

What about Sovereignty 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;

• Sorter replacement protocol.

Enforcement of inclusion mechanisms helps increase censorship resistance. This mechanism allows users to force inclusion of their transactions directly into the base layer. Any user on Rollup can then force-exit their funds back to the base layer. Therefore, even if there is only one centralized orderer node, it cannot censor users as long as there is a mature mechanism for enforcing inclusion.

But is that enough?

Even if users are free to exit, this may mean that if most users run back to L1, L2 wont have much incentive to continue operating. Additionally, forced inclusion mechanisms often require long wait times 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), and we can call it weak censorship.

Then we have the final activity attribute - ledger growth.

If the centralized ordering were to do evil, it could prevent the growth of the Rollup chain by simply stopping block production. If this happens, the user cannot take any steps to make the Rollup valid 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, Rollup is able to launch a new sequencer through governance. One way to achieve this is to replace centralized orderer nodes with decentralized orderer protocols. If the sequencer is decentralized and does not have a monopoly on Rollups block construction, then it will be nearly impossible to block the Rollup chain.

Therefore, while user funds are always safe in a Rollup implemented through a forced inclusion mechanism, establishing a strong sequencer replacement protocol helps keep the Rollup alive and provides practical, real-time censorship resistance.

this is all?

not completely. From a technical perspective, there is one more aspect to consider:

What if the smart contracts themselves could be upgraded by Rollups central committee? Assume that Rollup is currently implemented correctly, but tomorrow the committee reaches consensus and we no longer need smart contracts, but instead broadcast the proof 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 implementing the upgrade (although this is not a good user experience and may be bad for the business). This can be achieved through lagging governance updates, which act like a notice period after which the upgrade will be implemented. Users who do not agree to the updates may exit within the notice period.

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

Of course, this has its own problems. If there are any bugs in the code, or some major event requires updating the smart contract, then Rollups only option is to fork to a new smart contract, leaving user funds stuck in the old contract.

Unfortunately, the current state of Rollup is far from the complete implementation we discussed above. Most Rollups are still in the exploration stage and are struggling to be implemented correctly.

According to L2 BEAT, Fuel v1 and DeGate are the only two mature rollups that can achieve all liveness and safety conditions.

economic point of view

Finally, lets 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.

How quickly a transaction is finalized depends on how quickly the base layer is finalized. Whenever the data on L1 is finalized, the transaction can be considered final. However, users running full nodes can also obtain instant final results 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 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 sequencer alternative protocol solutions give up this property (as a disadvantage to users), others, such as the external PoS consensus scheme Espresso, can provide similar pre-confirmation guarantees without the risks of a centralized sequencer.

What about user costs?

The explicit cost of a Rollup transaction is usually:

L2 Gas Cost = L1 Gas Cost + Sequencer Fee. A rational centralized orderer 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 sequencer mechanism. Even PoS nodes in decentralized orderers want to maximize their profits.

In fact, this creates a mismatch problem, i.e. Rollup may not want to hand over profits to the external sequencer.

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 problems of Rollup handing over revenue to external mechanisms can be solved through a transaction agreement between Rollup and the external mechanism.

However, as Jon Charbonneau explained in his talk during the Modularity Summit and in subsequent articles, 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 detrimental effects of a centralized orderer.

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 forced inclusion and lagging update mechanism, user funds will be safe regardless of whether the orderer is centralized.

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