Rollup Decentralization - Does it matter?

Recently a lot of discourse on Crypto Twitter (Crypto X?) has been around the decentralization of L2s. Are the rollups we’re building decentralized enough? Or are they at least on the path to decentralization? Does it even matter?

I’ll explore these topics in this post. Before I dive in, if you’re still wrapping your head around how rollups really work, I’d recommend giving this a quick read: Rollups for Dummies

The idea of rollups is simple: We want offchain actors to be able to do transactions that can then be easily verified onchain. Through rollups, the base layer allows its foundation of “trust” to be leveraged for activities that happen away from its immediate scope. In return, rollups pay a small fee (rent) to leverage this trust.

So do we need rollups to be decentralized?

The intuitive answer is yes absolutely! That is the ethos around which we’re building blockchains.

However, I believe the answer to this question isn’t simply yes or no. Instead, it has multiple facets that must be analyzed separately. In the next sections, I will break down this question from 3 angles: philosophical, technical, and economical. These 3 aren’t necessarily exhaustive or exclusive but they should give a good overall perspective of the problem.

Philosophical Angle

Let’s first take the conversation one level higher - Why do we care about decentralization at all?

Well because we want a permissionless future that fosters open innovation. We want users to be able to build new things without any constraints, and without needing to trust any single entity.

In the short history of blockchains, we’ve already had so many anonymous devs who’ve built amazing stuff. In fact, Bitcoin itself was created by an anonymous entity - and it might very soon be the currency that most of the world uses for global payments! That is the power of Permissionless Innovation!

The decentralized foundation of trustless networks like Bitcoin and Ethereum enables us to build a future like that. Quite clearly then, any chains that have a trust relationship with these chains, like rollups, should be decentralized as well!

In fact, it begs an interesting and important question:

If rollups are not decentralized, does that imply Ethereum is not decentralized?

A slightly 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), completely permissioned chains - and the users of that rollup should still be able to leverage the security of the base layer. As long as the base layer is decentralized, and the rollups have been ‘fully’ implemented (we’ll talk more about ‘full implementation’ in the technical section), even permissioned chains should be safe to use.

But the practical reality is that most of the rollups today have not reached the fully implemented stage yet and they do not provide the desired level of security and trustlessness to their users.

So what does a proper implementation for a rollup look like? Let’s take a look:

Technical

To really understand the question of decentralization and security at the rollup level, we need to look at it from the first principles. And not many can explain the first principles of blockchains 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 view the network they can have different rules that they use to confirm the correct state of the network in their own ledger.

For example, in Ethereum, in the Gasper protocol, there are two distinct confirmation rules - an available rule (based on the heaviest chain) and a finalized rule (based on blocks confirmed by the gadget).

In rollups specifically, full nodes have different confirmation rules than the light clients. In traditional smart contract rollups (SCRs), the smart contract (validating bridge) has its own confirmation rule. If there are no adverse events, these confirmation rules coincide eventually in what can be called the ‘zone of concordance‘. As the name suggests, in the zone of concordance, all participants have the same view of the network (and the same history in their ledgers).

No adverse events would happen if all the confirmation rules are secure. As Sreeram shares in the thread above, 5 properties majorly define the security of these confirmation rules.

1. Ledger Growth - The rollup chain should keep growing (liveness)

2. Censorship Resistance - All users should be able to include any and all transactions to the base layer

3. Reorg Resistance - The transactions once finalized shouldn’t be reverted

4. Data Availability - Data of transactions should be published somewhere

5. Validity - Transactions and the state transitions should be valid

The first 2 properties together define the ‘Liveness’ condition of the system, while the last 3 define the ‘Security’ condition.

Let’s look at each of these from the perspective of different rollup participants and see what can be mitigated without decentralization.

Full Nodes:

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

So the security conditions remaining are the liveness properties and Reorg Resistance. For the latter, a full node relies on the validators of the base chain and the consensus protocol they use, and for the liveness properties, the full nodes rely on the sequencer and the rollup implementation.

Light Clients:

Most users interact with the blockchain using wallets that either have embedded light nodes or use a third-party service to obtain the blockchain data. Light nodes can be of various types:

• State verifiers - verify the validity of state transitions,

• DA verifiers - verify Data Availability,

• Consensus verifiers - verify proof-of-consensus of the base layer, or

• Full-verifiers - verify all of the above

If you run a full-verifier light client, you can verify that the 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 the state has finalized on the base layer by following the consensus of the base layer (on Ethereum, this can be done by following the sync committee).

Then the security conditions remaining are the liveness properties, for which the light clients rely on the sequencer and the rollup implementation.

Enshrined Smart Contract (Validating Bridge):

In traditional SCRs, the ‘confirmation rule’ of the smart contract is to enforce all 5 security properties:

• Ledger growth via a sequencer replacement protocol

• Censorship resistance by forced inclusion

• Reorg resistance by building only on the previous state

• Data Availability by committing DA on the base layer

• Validity via validity/fraud proofs

Full nodes of an SCR rely on the smart contract to enforce the liveness properties. They ‘absorb’ the reorg resistance from the base layer.

Light nodes rely on the smart contract to enforce liveness properties and absorb DA and Reorg resistance from the base layer. They can verify validity proofs themselves or through the smart contract.

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

What about Sovereign rollups?

Sovereign rollups don’t have a smart contract (validating bridge) to enforce validity or liveness conditions. Instead, they “roll down” proofs downstream to the rollup nodes. These nodes still absorb DA and Reorg resistance from the base layer.

Just like in SCRs, in sovereign rollups, nodes require some mechanism to enforce the liveness properties. And to define the canonical chain, they choose independent mechanisms like broadcasting p2p proofs.

What does all this have to do with decentralization?

Irrespective of whether it’s a smart-contract rollup or a sovereign rollup, the liveness properties are derived from a proper implementation of the rollup. As we have seen above, the proper implementation of a rollup necessarily includes two important components:

1. Forced inclusion mechanism, and

2. Sequencer replacement protocol

Forced inclusion can help enforce censorship resistance. This mechanism allows users to “force include” their transaction directly in the base layer. Any user on the rollup can then make a forced exit back to the base layer with their funds. So even if there is just one centralized sequencer node for the rollup, it can’t censor users as long as there is a mature forced inclusion mechanism.

But is this enough?

Even if users can exit this might mean that businesses don’t have much incentive to run if most users are running back to the L1. Also, often the forced inclusion mechanisms require a long waiting period and can be quite expensive to execute for an average user. The censorship resistance provided by such a mechanism isn’t exactly practical (or real-time). We can call such a scenario ‘weak censorship’.

Then we have the final liveness property - Ledger growth

If a centralized sequencer turns malicious, it can stall the growth of the rollup chain by simply halting block production. If this happens, there is nothing the users or businesses can do to make the rollup ‘live’ again.

To tackle this, we need a Sequencer Replacement Protocol.

The idea of a sequencer replacement protocol is the ability of rollup governance to boot the sequencer if it’s acting in a malicious manner. One of the ways of achieving this is by replacing the centralized sequencer node with a decentralized sequencer protocol. If the sequencer is decentralized and does not have a monopoly over building blocks for the rollup, then it becomes practically impossible to stall a rollup.

So even though user funds are always safe in a rollup implemented with a forced inclusion mechanism, establishing a robust sequencer replacement protocol helps maintain the liveness of a rollup and provides practical, real-time censorship resistance.

Is that all?

Not quite. There’s one more aspect to consider from the technical angle:

What if the smart contract itself is upgradable by a central committee of the rollup? Say the rollup is properly implemented currently, but tomorrow the committee comes to the consensus that we don’t need the smart contract anymore, but instead, we’ll broadcast proofs of the state of the rollup to the p2p network.

If as a rollup user, you don’t agree with such an upgrade, you should have the ability to exit the rollup before the upgrade is implemented (although again, this is not a good UX and probably not good for businesses). This can be achieved by ‘lagged governance updates’. This is like a ‘notice period’ after which the upgrade would be implemented. Users who aren’t aligned with the update can exit during the notice period.

On the decentralized extreme of this is the option of having completely immutable smart contracts. These contracts aren’t managed by any multi-sig wallets or other committees, and can never be upgraded once they have been deployed.

Of course, this comes with problems of its own. If there are any bugs in the code, or if some major event requires an update to the smart contract, the only option rollup nodes would be left with is forking off to a new smart contract - leaving the user funds stranded in the older contract.

The Current State

Unfortunately, the current state of rollups is far from the full implementation we have discussed above. Most rollups are still in the ‘training wheels’ phase and are working towards a proper implementation.

As per L2BEAT, Fuel v1 and DeGate are the only two rollups that have matured to achieve all liveness and security conditions.

Economical

Let’s look at rollup economics from the perspective of both the users and the rollup operators:

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

• Rollup profits - It should be profitable for the sequencers and token holders to operate the rollup

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

The speed of transaction finalization depends on the speed of block finality of the base layer. Whenever the data on the L1 is finalized, the transaction can be considered final for all intents & purposes. However, users running a full node can also get instant finality by simply executing the transactions themselves and determining what the final state would be.

But it is not practical for everyone to run full nodes. Therefore, a centralized sequencer is helpful as it can provide ‘soft confirmations’ to the users that their transaction has been included in a block and will be eventually finalized. This is more than sufficient for most use cases. However, it involves reliance on a central party that can take adverse actions.

While some of the sequencer replacement protocol solutions (like based rollups) give up on this property at a disadvantage to the users, other solutions like an external POS consensus (for example, Espresso) can provide similar pre-confirmation guarantees without the risks of a centralized sequencer.

And what about the costs to the users?

The explicit price of a transaction on a rollup is usually:

L2 gas cost = L1 gas cost + Sequencer fee

A central sequencer acting rationally would always want to maximize its own profits even if it means transferring higher costs down to the users. It is important to note, however, that this isn’t necessarily solved by a decentralized sequencer mechanism either. Even the POS nodes in a decentralized sequencer would want to maximize their own profits.

In fact, this creates a misalignment problem where the rollups might not want to give up their profits to an external sequencer.

Rollup Profits - In addition to the sequencer fee, rollups can also make profits by extracting MEV from the batch of user transactions. This MEV is often hard to attribute because it can be difficult to find if the sequencer included some of its own front-run transactions in the batch.

If a rollup is replaced by an external POS consensus, they give up this MEV to the external operators.

It is to be noted that both of these problems of the rollup giving up revenue to an external mechanism can be solved by “trade agreements” between the rollup and the external mechanism where the fees and MEV generated from internal and cross-rollup transactions can be redirected back to the rollup.

However, as Jon Charbonneau explained in his talk during the Modular Summit, and in a subsequent post, a better idea might just be for the rollup governance to delegate sequencing to a permissioned set of a few nodes. These nodes can be chosen strategically to be geographically decentralized and bad actors can be simply kicked out by the governance.

This is potentially a two birds one stone solution as it allows the rollup to keep the profits internal while also mitigating the adverse effects of a centralized sequencer.

But a counterpoint to this is that with a limited rotation of sequencers, the sequencers can have a non-myopic behavior that can lead to monopolistic pricing / price-gouging at the expense of the rollup users.

Either way, it is clear that some sequencer replacement protocol is necessary for the rollup to be economically efficient for the users. Whether it’s proof of governance, an external consensus mechanism, or something else, is a discussion for another post.

Conclusion

Hopefully, it is evident by now that irrespective of what path a rollup takes, it is crucial that the destination should be a complete implementation with mature mechanisms for sequencer replacement, forced inclusion, and lagged governance updates. Even just with forced inclusion and lagged updates, user funds are secure on a full-implementation rollup irrespective of whether the sequencer is centralized or not.

However, a robust sequencer replacement protocol boosts the liveness guarantees and possibly improves the economics for the rollup users.