Layer 2 (L2) Rollups have emerged as a key solution for scaling smart contract platforms. Ethereum Rollups like Optimism and Arbitrum have led this innovation. Still, newer models such as Midgard—an optimistic Rollup built for Cardano—introduce alternative architectures that challenge decentralization, permissionlessness, and finality assumptions. This article compares Ethereum Rollups and Midgard across core architectural dimensions, including decentralization, sequencing, conflict resolution, finality, and state models. We explore how Midgard provides a more deterministic and decentralized framework and highlight the trade-offs of current Ethereum-based designs. For a better understanding of the topic, read our introductory article about Midgard. L2 Prioritizes Scalability and Fast Pre-Confirmations Blockchains like Ethereum and Cardano prioritize decentralization, security, openness, and permissionlessness. In contrast, L2 rollups focus on high throughput and rapid responsiveness. A key benefit to users is fast pre-confirmation—a quick, optimistic signal from the Rollup that a transaction is accepted and likely to be finalized. To enable this, L2 systems typically forgo immediate finality in favor of processing speed. Coordinating decentralized consensus, as done in L1 networks, is too slow for the demands of real-time transaction inclusion. Instead, most Ethereum Rollups use centralized or semi-centralized sequencers to order transactions. Optimistic Rollups assume most transactions are valid and post their transaction data and state roots to L1. Each L2 block enters a "challenge window"—a defined period in which anyone can submit a fraud-proof if a protocol violation (e.g., double-spend) is detected. If no fraud is found, the block becomes final. But if a fraud-proof is submitted and verified, the block and any of its successors are invalidated, triggering a rollback. The challenge period can last hours or even days (e.g., 7 days in some Ethereum rollups), so true finality is delayed. Yet Rollups continue to produce blocks at a high frequency to meet throughput expectations, meaning that the latest state often advances ahead of the confirmed state. In the figure, the green blocks represent the confirmed state. The white blocks are in the challenge period. The transaction of Sender 1 was inserted into Rollup block 2 and subsequently into Ethereum block 15. Block 2 has passed the challenge period, making it immutable from the perspective of the Rollup. The transaction of Sender 2 was inserted into Rollup block 8 and Ethereum block 18. Block 8 is still in the challenge period. Although block 8 is stored in the Ethereum blockchain, it can be rolled back. The data (transaction inputs) remains stored on Ethereum forever, but the claimed result (state root) can be challenged and rejected. Both Sender 1 and Sender 2 receive a pre-confirmation from Rollup almost instantly after submitting the transaction. However, only Sender 1 can be sure that his transaction is finalized. I will delve into details later. The current state of Rollup is represented by block 12. While Rollups are said to inherit decentralization and security from their L1, this is only as strong as their integration and enforcement mechanisms. Fraud detection, dispute resolution, and data availability must be tightly coupled to L1 logic and require active participation from external actors like Watchers. UTxO vs. Account-Based Models At the core of Rollup architecture lies a key distinction: the state model. Ethereum Rollups inherit Ethereum’s account-based model, which maintains a single global state. Every transaction updates this global context—account balances, contract storage, and nonces—and must be strictly ordered. This global state must be sequentially replayable by every node. Because all transactions interact with the same shared state, even a small change can affect others downstream. Validity depends on prior state transitions, making it impossible to validate transactions independently or in parallel. The figure shows the construction of a new block. The new block depends on the shared global state, specifically on the last transaction (red transaction). The validation of the next transaction in the block (yellow transaction) depends on the previous one (green transaction). Midgard, like Cardano, uses the Extended UTxO (EUTxO) model. Here, each transaction consumes specific UTxOs and produces new ones. Transactions are local—they only affect the UTxOs they touch. There’s no need to coordinate a global transaction order. Conflicts like double-spends are resolved deterministically and without coordination. This localized execution model allows high parallelism and simple conflict handling. If two transactions try to spend the same UTxO, one is discarded. There’s no need to revalidate unrelated transactions. The figure shows the validation of block N. Each transaction consumes UTxO from the set of UTxO. The set of UTxO represents the context (global state) for validating new transactions (blocks). UTxOs are independent objects that must be spent in their entirety for new UTxOs to be created and added to the set of UTxOs. So, each new block updates the set of UTxOs. Note that the sequence of transactions does not matter. Sequencing and Coordination Ethereum Rollups depend on centralized sequencers due to the lack of a shared mem-pool and the ordering requirements of the account model. In account-based systems, transaction validity depends on ordering. To decentralize sequencing, multiple parties would need a consistent view of pending transactions. In the figure, you see 2 sequencers publishing their Rollup block to the Ethereum blockchain without coordination. Sequencer 2 could have inserted the same transactions into his block 9 as sequencer 1 into his block 8. Bob could have attempted a double-spend attack. The decentralization of sequencers requires coordination. Coordination of sequencers would require a shared mem-pool, among other things. A globally consistent mem-pool is difficult to build. It would require: Deduplication logic Prevention of transaction reordering MEV resistance mechanisms Synchronization to avoid forks or race conditions Without this, different sequencers might see conflicting transaction sets and create divergent states. Hence, centralized sequencers dominate Ethereum rollups—they simplify coordination by enforcing one global order. In the figure, you can see a shared mem-pool for sequencers. This allows Rollup to ensure the uniqueness of transactions in the sequence across Rollup blocks. Blocks 8 and 9 do not conflict with each other. Midgard avoids these problems. Thanks to its UTxO model, conflicts are binary and localized. Transactions are either valid (UTxO unspent) or invalid (already spent). There’s no shared state to coordinate. Midgard operators produce blocks sequentially during scheduled time slots (shifts) enforced by the Cardano-based Scheduler smart contract. Operators treat the latest unconfirmed block in the state queue as the working state. They can validate it before building their own block. If previous blocks are valid, their own block is likely to be finalized too. This provides safety with minimal overhead. Midgard blocks contain the current set of UTxOs. Adding a new block requires using the set of UTxOs from the previous block and validating new transactions against it. In the figure, you can see Midgard operator 1 adding block 6. The current set of UTxOs from block 5 was used for the state transition. The blue transactions spend the blue UTxOs. Midgard operator 2 added block 7. The red transactions spend the red UTxOs. It used the current set of UTxOs from the previous block 6 to validate the transactions. The green UTxOs are the newly created UTxOs after adding block 6. Notice that blue UTxOs are not present in the set of UTxOs after adding block 7 (they have been spent). The image shows the same scenario from a state transition perspective. State transition occurs through an update of a set of UTxOs. Transactions and consumed UTxOs are correlated in color. Green and purple UTxOs are newly created after transactions are processed (consumed UTxOs are removed from the set of UTxOs while new ones are added). The set of UTxOs from block 5 is the input for the state transition as are all transactions (events) from block 6. In other words, the set of UTxOs from the previous block is the validation context for the next block. For simplicity, we only consider Midgard transactions. Sequencing Conflict Example Suppose Alice submits two transactions: TX1: 5 ETH to Bob TX2: 5 ETH to Charlie She has only 5 ETH. If Sequencer A sees TX1 first, TX2 is invalid. If Sequencer B sees TX2 first, TX1 is invalid. Both transactions are valid individually, but not together. A decentralized system must resolve which came first. Without an agreed canonical order, forks and disputes are inevitable. Note that even if sequencing were not a problem (and both blocks 8 could be appended in an agreed order), Rollup would still need to protect against double-spend attacks. Ethereum Rollups could adopt Midgard-style shift-based sequencing using a Scheduler, but this wouldn’t solve the coordination issue. It would still require: A shared transaction mem-pool Consensus on inclusion rules Fork resolution strategies In effect, this would recreate L1 consensus complexity just for L2 sequencing. Let's see how easy it is to resolve a similar conflict in the case of the UTxO model. We will return to this topic later. The UTxO Model Offers Simpler Conflict Resolution In contrast, UTxO models make conflict resolution trivial. If two transactions try to spend the same UTxO, one is discarded. No prior state context or re-execution is needed. Example: Block N: TX_A spends UTxO_X Block N+1: TX_B also tries to spend UTxO_X → invalid The system can deterministically detect and discard TX_B. If both are in the same block, the block is invalid. During the building of a new block, the operator includes the first and drops the second (for example, based on the submission time of the transaction). No ambiguity. Midgard Validation and UTxO Context Validating a transaction in Midgard only requires knowing the current UTxO set. If the UTxOs it wants to consume are available and unspent, it’s valid. There’s no need to consider the order of other transactions in the same block. Conflicts are contained, and revalidation of unrelated transactions is unnecessary. This makes the system highly parallelizable, deterministic, and resistant to coordination issues. Transactions are processed independently, and each block is fully self-contained. In the figure, you can see that Midgard Operator 2 discarded the transaction it wanted to put into the block as the third one (but the order does not matter, I used the order just for the explanatory reason) because the transaction was trying to consume UTxO that had already been spent in the previous block. This did not affect the other transactions in the block 6. Why Ethereum Rollups Can’t Simply Use the Midgard Scheduler for Decentralized Sequencing A frequent question arises when comparing Midgard to Ethereum rollups: “Why can’t Ethereum rollups use a Scheduler like Midgard’s to assign sequencer turns and avoid conflicts?” At first, it seems feasible. Midgard uses a Scheduler Contract to assign operators fixed shifts, each producing one block. Operators only need the current set of UTxOs to proceed. Couldn’t Ethereum rollups do the same—Sequencer 1 builds on a known state, followed by Sequencer 2? The answer is no, due to fundamental differences between Midgard's eUTxO model and Ethereum's account-based model. Midgard's eUTxO model updates the UTxO set deterministically and locally. Each UTxO can only be spent by one transaction, so conflicts like double-spends are isolated and binary (they either happen or don’t). Transactions don’t rely on the global state or interfere with unrelated parts of the system. This allows operators to validate transactions independently, discarding conflicting ones without disrupting the block. Operators don’t need to coordinate or share a mem-pool—they simply follow the Scheduler's defined shifts, building on the latest valid state. This combination of turn-taking and deterministic logic makes Midgard conflict-resilient and parallelizable. Ethereum’s account-based model complicates things. Data availability isn’t just about storing transaction data; it also requires reconstructing the current state from prior transactions. Every block depends on the exact order and content of previous transactions, which can indirectly affect unrelated areas like contract logic. Sequencer 2 in Ethereum rollups can’t just rely on the latest state root; it needs the full transaction history and the order processed by Sequencer 1 to calculate the correct current state. Without this trace, Sequencer 2 can’t validate new transactions. A shared mem-pool is essential for coordination—without it, different sequencers might build on conflicting transaction pools, leading to diverging states. If Sequencer 1 withholds or delays posting its transaction list, Sequencer 2 is stuck and cannot proceed. In case of conflicts, all prior transactions must be replayed to locate the divergence, making consistency and traceability critical for Ethereum rollups. In Midgard, only the UTxO set needs to be passed between operators. Each block locally and deterministically transforms the UTxO set, ensuring fast and straightforward validation. Operators retrieve the UTxO set from the Data Availability Layer and verify new transactions by ensuring inputs are unspent. This avoids replaying entire transaction traces and makes Midgard efficient and compact. In Ethereum rollups, sequencers must download transaction data and replay the entire state to proceed, which slows the process. Both systems depend on DA Layers, but Midgard only requires checking UTxOs, whereas Ethereum must handle full state reconstruction. While Midgard's Scheduler enables smooth and conflict-free operation due to its deterministic UTxO model, Ethereum’s account-based model and reliance on the global state make such an approach impractical without introducing significant complexity. Decentralization and Openness Most Ethereum rollups are operated by the same team that built them. These teams control the sequencer, the prover, and the fraud or validity-proof infrastructure. Even though Ethereum enforces immutability once data is posted, the team decides: What gets posted In what order When it gets posted (or not posted at all) By whom fraud-proofs can be submitted Whether a fraud-proof is accepted Some rollups support forced inclusion (e.g., Optimism), but this often involves delays, special transactions, or allowlists. In practice, if the sequencer ignores your transaction, it may never be included. Decentralization works only when multiple independent entities with diverse preferences, ideologies, or business models are involved. In a centrally controlled system, there’s no alternative to challenge or correct the decisions made by a single authority. For instance, if a central authority decides to block Bob's transactions, no other team (or sequencer) can step in to include them in a block. L2s, just like blockchains, must remain open to participation by anyone. If this openness isn’t guaranteed, users are forced to rely on and trust a single controlling authority, defeating the purpose of decentralization. Let's explain under what circumstances a team can initiate a rollback. Each new Rollup block contains a batch of L2 transactions processed by the sequencer. When the sequencer submits a block (in a compressed form) to Ethereum, it includes the transaction data (as calldata or blobs). After processing these transactions, a new state root is created, representing the updated state. Each block generates a new proposed state root, even if previous blocks are not yet finalized. State roots are stored as an internal history in the rollup's smart contract or off-chain infrastructure. However, only the latest pending or finalized state root is treated as the "current" state. Each state root summarizes the rollup’s entire state using a Merkle root, which is a cryptographic summary (or fingerprint) of the data, not the data itself. During the challenge period, anyone can submit fraud-proof if they find an incorrect state root. Until this period ends, the state root remains pending. Despite this, the rollup continues to build new blocks optimistically on top of the pending root, creating a chain of unfinalized state roots, each depending on the previous one. The rollup's smart contract enforces strict rules. State roots can only be invalidated during the challenge period, and only if valid fraud-proof is submitted and verified. Once the challenge period ends, the state root becomes final and cannot be changed arbitrarily. However, in many rollups today, the team can still rewrite history. This is because some rollups use upgradeable contracts or retain admin keys. If the admin has control, they can alter the logic or storage even after the challenge period, redefining what is considered canonical. Until these admin keys are removed and smart contracts become immutable, users must trust the team not to act maliciously. In the figure, you can see that Alice's transaction was included in the Rollup block. The team later decided to change the history and not include Alice's transaction. In Midgard, users can submit transactions via Cardano L1 smart contracts. Fraud proofs can be submitted by anyone. There are no allowlists or special permissions. Anyone can register as an operator or act as a Watcher. Even if all operators go offline, Midgard users can still force protocol execution via Cardano. All block production and fraud resolution logic is enforced by smart contracts. This makes Midgard more open and permissionless than most Ethereum rollups. In the figure, you can see that all Midgard processes are controlled by deterministic smart contracts that are accessible to everyone. No admin keys will be used. Users do not have to trust the team. Midgard will be fully trustless. Do Not Be Evil vs. Cannot Be Evil Ethereum rollups rely on teams to behave correctly. If the backend censors, delays, or misbehaves, users are often powerless. This model is built on "do not be evil." Midgard is built around "cannot be evil." No centralized actor controls state transitions. Smart contracts enforce all protocol rules, and anyone can monitor or intervene. Power is distributed across many actors with different incentives, making the system more robust and resilient. Finality and Fraud Proofs In Ethereum rollups, finality is determined by what the sequencer chooses to publish to L1. The team controls batch creation and proof submission. Although L1 guarantees immutability, the rollup infrastructure controls what becomes final. This is the "trusted publication problem": users must trust that the sequencer will publish their transaction, even if the L1 smart contract allows for inclusion. Midgard eliminates this problem. Once a block is submitted to the State Queue, it can be independently validated. If valid and unchallenged, it is merged into the confirmed state. Finality is deterministic and governed by Cardano smart contracts. Anyone can submit fraud proofs. Anyone can act as a Watcher. There is no backend dependency. The Scheduler plans operator shifts but does not influence finality. Once a block passes the challenge window, it becomes final. The State Queue Contract, the Settlement Queue Contract, and the Fraud-Proof Contract control the finality. Midgard users can gain immediate confidence in transaction finality. This is called "safe optimistic finality." If a user (or their wallet) acts as a Watcher, they can validate that a block is correct. If no fraud-proof is possible to submit (all rules were followed.), the block will be finalized. This allows users to act on unconfirmed state with high confidence, knowing that any invalid block will be provably rejected. Conclusion Ethereum Rollups bring scalability but inherit centralization trade-offs. They rely on sequencer-controlled infrastructure and struggle with decentralized sequencing due to shared-state complexity. Decentralizing rollups means reintroducing consensus, just under a different name. Midgard, built on Cardano’s UTxO model, embraces determinism, permissionlessness, and decentralization. With on-chain enforcement of sequencing, validation, and finality, Midgard provides a cleaner and more robust architecture. Ethereum Rollups today trade decentralization for speed. Midgard trades speed for decentralization—and builds a more resilient, trustless system as a result. Even though Midgard might not match the raw speed or UX of some Ethereum rollups, it’s more decentralized and trust-minimized, which aligns better with the blockchain’s original values.
