This post explores definitions and high-level ideas of rollup decentralization. It does not cover deep technical detail about decentralizing rollup implementations.

We identify Taiko as a decentralized Ethereum-equivalent ZK-Rollup. Ethereum-equivalent - the moniker of a type-1 ZK-EVM - is a technical design decision that we describe here.

In this post, we’d like to talk about the other descriptor in that statement: decentralized. We will explore:

• What is the definition of a decentralized rollup?

• How do you decentralize a rollup?

• What are the tradeoffs of a decentralized rollup?

• Taiko’s approach: progressive efficiency

• Decentralized implementation & decentralized governance

• How decentralization is part of Ethereum-equivalence

You may be surprised (or not) to learn that there is some disagreement on the definition of a decentralized rollup. We think we can get pretty close to a widely accepted definition, though:

A decentralized rollup is one where any user can be sure that their transaction will be executed.

We should take a moment to ask why one may even care whether a rollup is decentralized or not. Given that rollups rely on L1s for security guarantees (mainly Ethereum these days for the leading rollups), aren’t users covered no matter what?

Rollups guarantee that as long as the L1 (data availability layer) exists, users can reconstruct the L2 state and exit the rollup by forcing a transaction on L1. If the system doesn’t satisfy this constraint, then we would say it does not constitute a rollup; it is a different type of L2 or a sidechain. This should make it clear that choosing a strongly decentralized (always live, censorship-resistant) L1 is crucial. One further nuance is that for a general-purpose rollup, as opposed to an app-specific rollup, users must be able to force the inclusion of any arbitrary transaction, not just ‘exit’ transactions.

Once established that we are talking about a rollup, we put forth that the distinction that defines a rollup as decentralized or not lies with how difficult or realistic it is for a user to be able to force their transaction to be included. For instance, do they need very powerful computing resources to generate a ZK proof? Or can they use consumer hardware or rent a cheap server for a short amount of time? Is there some privileged actor that has free reign for an extended period, relegating one’s ability to try to be included to be delayed by 30 days? The less prohibitive, the more decentralized.

In reality, a typical user would likely wish to avoid running a full rollup node, and in the case of a ZK-Rollup, the prover add-on. They would like to know that the rollup they transact on - or maybe even the rollup they call home - is conducive to having a wide and diverse set of participants perform the necessary functions. And that new participants can join the network to perform these functions, permissionlessly - including themselves, if they so wish.

With the above in mind, let’s finish this section with another definition of a decentralized rollup to help us gain a better understanding:

A decentralized rollup is one where multiple parties can participate in each network position - that is, as proposers, provers, and node runners.

This leads us to the next section.

Given the above definitions, especially the second one, you may see that we can decentralize a rollup by ensuring all roles can be performed by multiple parties - ideally a vast and geographically-diverse set. Those roles are:

• Proposers

• Provers

• Node runners

Before we review each role, let’s simply review a point touched on in the prior section: rollups, as an L2 solution, decide which L1 they are looking to scale, or more accurately, which L1 they will use for security guarantees. “Security guarantees” here means relying on L1 for consensus and data availability (DA). While this is not something that the rollup itself can tune towards decentralization, choosing a sufficiently decentralized L1 is a critical decision, and Taiko chooses Ethereum for the most robust security guarantees.

On to the roles.

Proposers construct rollup blocks from users’ L2 transactions and propose them to L1. Sometimes these are referred to as Sequencers in other rollup systems.

Proposers decide which transactions to include in a block and how to order them. This is a powerful position as it can extract profit from transaction ordering and decide which transactions to exclude, and is thus able to censor certain transactions, applications, or users.

As we established —> a decentralized rollup should allow users to expect the inclusion of all of their valid transactions.

Provers generate SNARK proofs asserting the validity of L2 transactions and blocks from the aforementioned proposed blocks.

Provers decide which proposed blocks to turn into on-chain verified blocks. This position decides when a block can reach its on-chain verified state, but not which txs go in a block or how they are ordered. Until this on-chain verified state, the prover can leave hanging certain transactions that depend on the validity proof, or leave hanging certain would-be on-chain verified blocks that are waiting for their parent block to be on-chain verified.

As we established —> a decentralized rollup should allow users to expect verification of all of their valid transactions.

Node runners execute transactions from on-chain (L1) data to stay in sync with the rollup state.

Proposers and provers need to run full rollup nodes to fulfill their respective roles. Other actors would also want to run nodes, such as those offering services like a block explorer, infrastructure providers, and users who want to stay in sync with the chain state for other reasons.

As we established —> a decentralized rollup should allow users to expect the execution of all of their valid transactions.

Note: while decentralizing proposers/provers is an explicit rollup protocol decision (e.g. the smart contracts may be configured to only accept blocks or proofs from allowlisted addresses), running a node is mostly a resource consideration that depends on state growth, hardware requirements, etc., and is not an outright protocol decision. Catering to reasonable state growth is critical, but is not discussed in this post.

Moving along a spectrum of centralization to decentralization exposes a tradeoff space.

For this section, the pros and cons apply to both proposers and provers (which we collectively term operators); we will leave out node runners, as mentioned, but keep in mind that running a rollup node is a requirement for both roles.

In the context of rollup proposers/provers, we view the following:

The current approach chosen by most in-production general-purpose rollups has been one of centralization at first, with a commitment to progressive decentralization over time. This has made some sense, as there are several moving pieces, assumptions to test, and it is early. Having a centralized proposer and prover (aka sequencer and validator in broader terms) has made it more simple to ensure the proper and efficient functioning of the rollup. We can see this popular approach in the below table.

Taiko, on the other hand, aims to go live with a fully decentralized (and permissionless) proposer and prover set. The protocol will not enshrine or allowlist any parties; anyone will be able to perform those duties. Further, Taiko plans to have a minimal protocol-defined coordination scheme for proposers/provers. The current plan is for it to be leaderless.

All rollups will choose the sweet spot that suits the needs of their users. That spot will be different across rollups, and the path to reach the same spot may also be different. You can start centralized and loosen control, or you can start decentralized and implement tight coordination rules (or perhaps even assign control). It is certainly possible that some of the decentralization disadvantages are impediments to a suitably performing network, at which point Taiko can implement measures such as leader election schemes to avoid redundant work.

In this sense, Taiko’s approach may be considered progressive efficiency, as opposed to progressive decentralization; moving from the completely decentralized and unstructured extreme, and more towards the middle, if needed.

This is not to say that Taiko will be completely “training-wheel-free” from the beginning. Certain measures like smart contract upgradeability will remain in place until things are battle-tested. This is guided by a security-minded approach: without proxy-based upgradability, users’ assets can face significant bug risks. Controlled upgradability is one of the levers that will be handed over to the DAO at some point.

Vitalik recently wrote that “decentralized governance structure protects against attackers on the inside, and a decentralized implementation protects against powerful attackers on the outside.” This was said in the context of DAOs - that is, both the governance structure and implementation pertained to DAOs. Specifically, it was said for one aim of DAO decentralization: robustness.

We think it is quite helpful to use this framing for rollups at large and split “governance structure” into meaning a rollup’s DAO, full stop (taking for granted the governance implementation is smart contract based), and “implementation” into meaning the rollup’s architecture itself.

In this light, we have so far discussed how a rollup can defend itself against outside threats (censorship, liveness failures) with a decentralized implementation. We mustn’t neglect how a rollup can defend itself against internal threats - against the organization and community charged with initially building and maintaining it. The tool at a rollup’s disposal here is governance, or simplified, its DAO.

When it comes to governance, Taiko adopts an approach that is similar to other rollups, and similar to most protocols on Ethereum in general, from DeFi to infrastructure. This approach is indeed one of progressive decentralization: control over the protocol will gradually be relinquished to the community, specifically to the Taiko DAO. It is too early to describe the details of the DAO and which governance mechanisms we would propose it adopts, but this will be the subject of future posts.

As a final thought on this topic: we view that implementation offers a point-in-time analysis of a rollup’s properties, while governance can describe how the implementation may change over time, and which parties can make those decisions.

On its quest for pure Ethereum-equivalence, Taiko highly values its prioritization of decentralization. It would seem odd to have equivalence as a goal encompass the EVM, hash functions, state and tx trees, etc., without also connoting equivalence in network composition.

Emulating Ethereum for Taiko means everything aligns towards Ethereum: the ZK-EVM, other Ethereum base layer architecture, philosophical considerations, community, and ~vibes~. This extends to network decentralization and the main properties it provides for developers and their users: censorship-resistance and liveness.

Thanks for reading.

Explore open positions on our job board.

To stay updated on the latest from Taiko:

• Website: https://taiko.xyz

• Discord: https://discord.gg/taikoxyz

• GitHub: https://github.com/taikoxyz

• Reddit: https://www.reddit.com/r/taiko_xyz

• Twitter: https://twitter.com/taikoxyz

Contribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the contributing guide.