Security Analysis

This page will provide a comprehensive overview of the security and scalability properties of Fuel as it compares to other so-called "scaling solutions." It argues that Fuel is uniquely positioned in the trade-off space to be the best scaling architecture today.

Common Definitions

We must first begin by establishing common definitions for desirable properties in a scaling solution. The following definitions are informal, but sufficiently precise to enable proper discussion on the matter. Note that they apply to both "layer-2" constructions as well as base "layer-1" blockchains.

Security Security can be roughly defined as the cost to manipulate history. Example: the security of Proof-of-Work blockchains can be measured as the capex and opex of producing new blocks. The security of Proof-of-Stake blockchains can be measured as the penalty that can be applied if a history re-organization is done.

Trustless Trustlessness has two components: state liveness and state safety. State is live if it can be consumed by its owner in finite time (in other words, it cannot be burned/locked forever), and safe if it cannot be consumed by its non-owners ever (in other words, it cannot be stolen). This is a more precise concept than non-custodial. It is critical to evaluate the trustlessness of a system across both these dimensions, not only state safety. It is also critical to consider worst-case scenarios (i.e. failure modes), not only the optimistic case.

Decentralized blockchains cannot be completely trustless; to illustrate, consider that 51% of miners in a Proof-of-Work blockchain could censor any future transaction (effectively burning censored funds, which allows for indirect theft) or even re-organize the history from genesis to steal all funds. Therefore we measure trustlessness as the assumptions under which a system is trustless. As an example, if we assume 51% of miners are honest, then a blockchain is trustless. We can describe a system that is almost as trustless as another as trust-minimized with respect to the other (e.g. a trust-minimized sidechain is trustless under almost the same assumptions as its main chain).

Permissionless A system is permissionless if it requires no in-system action for a new user to begin participating. It is permissioned otherwise.

Decentralization While commonly (and incorrectly) described as "the number of nodes," decentralization is measured as the cost to run a fully validating node. Actually running a full node at all times is not required, but we must consider the worst-case scenario of having to run a full node. While permissionlessness is a necessary property for decentralization, it does not otherwise provide a metric for measuring decentralization. Note: this definition is actually missing a very important detail, but will suffice for now.

Scalability and Throughput Often a point of contention and confusion, scalability is front-and-center as the most obvious problem for contemporary blockchains. First, throughput is the total transaction throughput of the system, measured in transactions per second. This is often the metric incorrectly advertized as scalability. Scalability is the ratio of total transaction throughput to cost of running a node. Therefore, comparing transactions per second between two systems without simultaneously comparing their costs is comparing apples to oranges. It is trivial to increase throughput by just increasing the cost to run a node, but that is not an increase in scalability.

Note: It is critical to consider worst-case scalability, not average-case or optimistic-case. Blockchains are adversarial environments; if something can be griefed and DoSed it will be griefed and DoSed.

Note: While the naming of the above properties may certainly be debated, that they are desirable properties in any scaling solution, and good metrics for evaluating such solutions, cannot. Trustlessness is especially critical; consider needing to choose between using an unscalable decentralized blockchain and a high-throughput custodial exchange. Neither option is even a choice.


In order to be a "good" layer-2 scaling solution, we need the following properties simultaneously:

  1. The system must have equal or almost-equal security to the main chain. Non-trivial trade-offs in security are unacceptable from a scaling solution.
  2. The system must be trust-minimized with respect to Ethereum. Adding meaningful trust assumptions, similar to reducing security, is unacceptable.
  3. The system should be permissionless. This is not a hard requirement, so long as the system is trustless, but is highly desirable.
  4. The system must have higher throughput than Ethereum.
  5. The system should be more scalable than Ethereum. In the context of decentralization (cost of running a full node): the marginal cost of each layer-2 transaction must be lower than the marginal cost the same transaction at layer-1.
  6. Additional desiderata include:
    • No need for hot keys
    • Backups support, only private keys are sufficient to recover funds
    • No novel cryptography
    • Capital efficient
    • Low latency
    • Generalizability/expressivity

Lastly, similar decentralization to Ethereum: running a node for the layer-2 must not be more expensive than running a full node for Ethereum. Note that this is a deployment parameter, and is not intrinsic to any of the schemes discussed here. To have a common basis for comparison: we want to be able to handle more transactions in our layer-2 than layer-1 Ethereum (with the same or similar trust assumptions), with the same hardware.

Put another way, everyone who could ever be interested in a particular interaction must fully validate that interaction (trust-minimization). If a layer-2 interaction is cheaper to validate than it would have been to validate on layer-1, then the layer-2 system provides scalability. If there are trustless guarantees that a particular interaction does not need to be validated by all users, then this can increase total transaction throughput without proportionally increasing full node costs (i.e. unconditional scalability). If there are no guarantees of this, then there may be conditional scalability, usually by deploying multiple instances of a scaling scheme with different participants.


Channels are one of the earliest blockchain scaling proposals. Originally taking the form of payment channels, they can be extended to arbitrary computation with state channels.

A fixed set of participants open a channel with an on-chain transaction that defines the rules of the channel. Updates to the channel state are made by unanimous consent: all participants signing a state update, communicated off-chain. Any participant may attempt to close the channel on a particular state, which starts a timeout during which anyone may submit a later state to penalize a fraudulent channel close attempt. If no later state has been shown by the timeout, the channel closes, settling balances based on the closing state.


  1. Same security as the main chain. Channel updates are not timestamped to Ethereum, so technically it is possible to manipulate the channel history, but only under the same failure mode as a trust-minimization failure (below).
  2. Trust-minimized, with an additional trust assumption: if the majority of miners censor transactions (which requires attacking the main chain), a proof of fraudulent channel close attempt can be censored, allowing theft of funds. Miners can already indirectly steal funds through censorship of the main chain, so this is not a meaningfully stronger trust assumption.
  3. It is permissionless to open a channel, but participation in any specific channel is permissioned and fixed. This means e.g. Uniswap cannot be implemented using only channels.
  4. The total aggregate throughput can be substantially increased by using channels.
  5. For a single channel, scalability depends on the execution model used, but it will usually be much cheaper to execute a transaction in a channel than it would be to validate it on Ethereum. For multiple channels, there is conditional scalability if the sets of participants is disjoint, which is usually the case since open-participation systems cannot be built with channels in the first place.
  6. Additional concerns:
    • Hot keys are required to take advantage of the low latency of channels.
    • Backups are not possible, only copies (backups can recover everything but a delta, while copies are all-or-nothing). Only the latest channel state is useful, and in fact old channel states are worse-than-useless as attempting to close the channel with an old state will result in a penalty. Private key backups are insufficient to ensure funds cannot be lost.
    • Capital inefficient: funds must be locked up inside a channel before being used, and cannot be unlocked quickly without cooperation from the specific channel participants.
    • Instant finality: as soon as a state update is signed unanimously, it is instantly finalized.
    • Generalizable to contracts between a fixed participant set.

In summary, while trust-minimized, channels make enormous sacrifices in terms of capital efficiency, user experience, and open participation to achieve instant finality, which is a feature not possible with blockchains. As such, unless instant finality is a critical requirement, channels are unsuitable as a scaling solution.

Channel Networks

Channel networks link together multiple channels with atomic multi-channel interactions. This allows for interactions between distinct channels, but still does not allow open participation on a shared state (i.e. Uniswap cannot be implemented using a channel network). They are unreliable unless an overwhelming majority of channel network participants are online simultaneously, which facilitates and aggravates a number of attacks.

In summary, channel networks do not diverge meaningfully from channels in the trade-off space.


Sidechains are blockchains that fully validate another blockchain as part of their consensus rules (e.g. a sidechain to Ethereum is a blockchain that validates the Ethereum chain). There are a number of ways sidechain blocks can be produced, including Proof-of-Authority (PoA, a single block producer), a federation, Nakomoto Consensus with Proof-of-Work (PoW), or even a consensus protocol using Proof-of-Stake (PoS) for Sybil resistance.

The two-way peg design of the sidechain (i.e. the mechanism for locking tokens for use on the sidechain, then unlocking them back to the main chain) is critical. A trust-minimized two-way peg is ideal, but is not feasible with plain sidechains.


  1. Sidechains can have the same security as the main chain by timestamping sidechain block header hashes on the main chain.
  2. A trust-minimized two-way peg is not possible with plain sidechains, since data withholding is not a uniquely attributable fault. A sidechain that adds features to make its two-way peg trust-minimized ends up becoming a Plasma or a rollup.
  3. Due to data withholding, sidechains degenerate to being permissioned: a cabal of sidechain block producers can create a block that other sidechain block producers can never build upon.
  4. Any number of sidechains may be deployed in parallel, so throughput can be greatly increased.
  5. Sidechains may have any execution model. As such, they can have a different—and more scalable—execution model than the main chain.
  6. Additional concerns:
    • Sidechains are flexible: they can be faster, cheaper, and more expressive than the main chain.

In summary, plain sidechains have a number of nice features, namely their flexibility, but are not trust-minimized. As such, they are unacceptable as a scaling solution.


Plasma is a scheme for trust-minimized but permissioned sidechains with exponentially lower on-chain costs. This requires transaction data to be kept entirely off-chain. Different flavors of Plasma (described below) have some common elements. Each Plasma block header is submitted by an operator to a contract on Ethereum (which means Plasma has at least as high a latency as Ethereum). Withdrawals from the Plasma chain (i.e. exits) are involved, and are what allows for (in theory) a trust-minimized two-way peg.

All Plasma variants are permissioned, or degenerate to become permissioned. Even if more than a single operator is used (e.g. using some PoS protocol for Plasma block production) a cabal of operators can produce a block and withhold data, preventing other operators from ever building upon it. In fact, using PoS for Plasma block production is actively detrimental and worse-than-useless, as it adds friction and cost to end users without actually providing any of the nice properties of PoS-based consensus protocols. This is because we cannot recover from PoS consensus failures without hard forks, and it is impossible to trustlessly upgrade a smart contract.

This scaling scheme has mostly been abandoned in favor of rollups for additional reasons that will become apparent soon.

Plasma MVP

Plasma MVP variants were the first concrete flavor of Plasma. A Plasma operator aggregates transactions off-chain, then commits to them in a Plasma block header that is processed on-chain. The UTXO data model is used, but the accounts data model can be used just as well. Exits are initiated on Ethereum against any block. If an exit is invalid (e.g. trying to exit a spent coin), a fraud proof can cancel it; otherwise, the exit is placed in a priority queue based on Plasma block number. After a timeout, the exit can be completed and funds withdrawn from the contract.

However, since Plasma block data can be withheld, the operator can create an invalid Plasma block that gives them all funds, then exit them. Block data is unavailable, so no one can prove the exit is fraudulent. Therefore all users must exit before the timeout expires by exiting their funds from an earlier (available) Plasma block than the malicious operator's exit. This is called a mass exit, an involves putting the Plasma chain's entire state onto Ethereum in a short amount of time.


  1. Security is borrowed from the main chain, as Plasma blocks are timestamped by Ethereum.
  2. Plasma MVP variants are only trust-minimized in theory. In practice, mass exits allow an adversary to start an attack with constant cost (posting a single invalid Plasma block header on-chain) that requires unbounded cost to defend against (users must exit the entire state in a short time, and state is essentially unbounded in size). Therefore Plasma MVP variants degenerate in practice to sidechains.
  3. Plasma MVP is a Plasma and thus permissioned.
  4. Plasma MVP may have higher throughput depending on the execution model. However, this is purely dependent on the execution model (and has no relation to having a single operator), as all users must fully validate the Plasma MVP chain to ensure their funds are safe.
  5. Increased scalability is possible with a more efficient execution model than the EVM.
  6. Additional concerns:
    • No need for hot keys.
    • Since data is not available on-chain, users must save a copy of their off-chain state. Private key backups are insufficient to ensure funds cannot be lost.
    • Capital efficient for both users and the operator.
    • Latency cannot be lower than Ethereum, as Plasma blocks are only valid once they are committed to Ethereum.
    • Ethereum-style smart contracts are not possible on Plasma. Predicate spending conditions on UTXOs are possible.

In summary, Plasma MVP variants degenerate to sidechains, with funds being trivial to steal by the operator. As such, they are unacceptable as a scaling solution.

Plasma Cash

Plasma Cash variants are the second concrete flavor of Plasma. As with Plasma MVP, a Plasma operator aggregates transactions off-chain, then commits to them in a Plasma block header that is processed on-chain. However, unlike Plasma MVP, a coins data model is used, where each state element is a non-fungible coin (similar to a channel, each coin is uniquely identifiable and cannot be broken up or combined). In order to accept a coin, its entire transaction history must also be downloaded and validated. Exits are initiated on Ethereum against any block. An invalid exit can be disputed or challenged (explained below); otherwise, after a timeout, the exit can be completed and funds withdrawn from the contract.

Since each coins has a distinct owner, each user only needs to check exits that try to withdraw coins they own. There are two distinct exit challenges:

  1. Non-interactive: the exit is spending an spent coin, and you can prove you owned this coin at a later time, within a timeout.
  2. Interactive: the exit is spending a coin that you currently own. This is challenged by asking for a valid spend for your currently-owned coin (which should not exist). This can be responded to or not, within a timeout.

In order to always be able to respond to the challenges above, the entire history of a coin (in the form of inclusion and exclusion proofs) must be kept, for each coin. This can quickly become enormous. Attempts to compress this history have led to research dead ends, or involve simply posting transaction data on-chain (i.e. degenerate to a rollup).

Users must verify their coins haven't been exited at least once per timeout to ensure safety. However, due to the interactive challenge, watchtowers cannot be used instead, so users must do this themselves.


  1. Security is borrowed from the main chain, as Plasma blocks are timestamped by Ethereum.
  2. Plasma Cash variants are trust-minimized in the same way as channels, with a synchrony assumption on main chain censorship.
  3. Plasma Cash is a Plasma and thus permissioned.
  4. Throughput can be substantially higher than Ethereum, as each user only needs to validate the history of coins they own, not the entire Plasma chain.
  5. Scalability is conditional on the number of coins a user owns. If the user owns sufficient coins, it might be more expensive to download and validate inclusion and exclusion proofs than fully validating Ethereum.
  6. Additional concerns:
    • No need for hot keys.
    • Since data is not available on-chain, users must save a copy of their off-chain state. Private key backups are insufficient to ensure funds cannot be lost.
    • Capital efficient for both users and the operator.
    • Latency cannot be lower than Ethereum, as Plasma blocks are only valid once they are committed to Ethereum.
    • Ethereum-style smart contracts are not possible on Plasma. Predicate spending conditions on UTXOs are possible.

In summary, Plasma Cash is trust-minimized, unlike Plasma MVP. However, it is permissioned, requires enormous off-chain cost to transfer coin history, and requires users to store state lest they lose their funds. As such, it is unsuitable as a scaling solution.


Validium is a Plasma-like protocol that uses validity proofs instead of fraud proofs and a synchrony assumption. In plain English:

  • Validity proof: succinct (exponentially cheaper to verify) proof that some computation has a certain result.
  • Fraud proof: proof that the result of some computation was incorrect. Requires a synchrony assumption (i.e. a timeout), after which the result is deemed correct if no fraud proof was submitted.

Validium has the benefits over Plasma of not having to worry about the operator producing an invalid block, and being resistant to miner censorship attacks for state safety. This means Validium blocks can be considered immediately finalized, while Plasma blocks are only finalized after the fraud proof timeout has expired. However, the production of validity proofs is expensive and has higher latency, involves novel and hard-to-audit cryptography, and may require a trusted setup.

There is one issue: how do we handle exits? Sure, the operator cannot steal user funds, but they can lock/burn user funds. We must always analyze both state liveness and state safety. In a Validium, as in a Plasma, block data is kept off-chain. As such, users may not have the state at the latest block, which would be required to exit seamlessly. We have a few choices:

  1. Users initiate an exit on Ethereum, and the operator must process it with a validity proof within some timeout (or provide a proof that the exit is invalid), otherwise the Plasma chain halts. This does not work, as it does not guarantee users can exit since the operator can simply stop processing anything.
  2. Users initiate an exit on Ethereum, and if it is not processed by the operator within some timeout, it is force-processed, unless proven invalid with a fraud proof. This means a user can get an invalid exit processed, which defeats the point of using validity proofs.
  3. Users initiate an exit on Ethereum, and if it is not processed by the operator within some timeout, the Validium chain rolls back to a previous block. This means we no longer have immediate finality. If we allow unbounded roll back, then there are no finality guarantees ever (which is unacceptable). If we allow bounded roll back, then that introduces a synchrony assumption which can be used to steal user funds.

Surprisingly, there is no way to ensure state liveness without re-introducing a synchrony assumption, which makes using validity proofs worse than useless!

Note: Synchrony assumptions can often be obfuscated. From the last link above: "The assumption is that we can recover to a state based on a history that took place not more than k batches ago." This k is a synchrony assumption, and user funds can be stolen if it is violated.

In summary, Validium does not actually exist as a separate cryptoeconomic system than Plasma. The use of validity proofs is superfluous, and increases latency and cost for no concrete benefit.


Different flavors of rollups have many common features:

  • Anyone may construct a rollup block (permissionless), and post the entire block to an Ethereum smart contract as calldata. The rollup block is not validated in the contract; instead, block validity is ensured by either a validity proof (ZK rollups) or a fraud proof + synchrony assumption (optimistic rollups). Since rollup block data is available, we can guarantee that block production can always be permissionless, unlike Plasma.
  • Withdrawals are initiated on the rollup chain, not Ethereum. Because of this, it is critical that anyone can have a transaction included into the rollup chain in bounded time. This means there is no requirement to monitor and challenge individual exits as in Plasma.
  • Rollups borrow security from Ethereum, as all rollup blocks are timestamped on Ethereum. As such, the latency of a rollup chain cannot be lower than Ethereum's blocktime.
  • Rollups may provide conditional scalability if multiple instances of a rollup (or multiple different rollups) are used, essentially as a form of heterogenous sharding. How much scalability this provides depends entirely on how often cross-rollup (similar to cross-shard) interactions happen.

Note: An alternative to permissionless block production is permissionless withdrawals only (but permissioned block production). This only works by halting the rollup chain if a withdrawal request isn't processed within some timeout. While technically trust-minimized, this is sub-optimal: exiting from the rollup may be very expensive, especially if the rollup has a lot of state.

ZK Rollups

ZK rollups were first concretely proposed by Barry Whitehat, and later refined and simplified.

In ZK rollups, each rollup block posted to the contract must be accompanied by a validity proof (a succinct proof that the block is valid), which is also verified by the contract. Blocks are thus finalized immediately, and withdrawals can be processed in the same Ethereum block. The block posted as calldata only includes sufficient information to apply each state transition (transaction). Witness data (signatures) can be excluded, as the validity proof proves that such signatures exist and are valid.

Users must do the following work to ensure their funds are safe:

  • Audit the circuit, which involves novel cryptography.
  • If a trusted setup is used, participate in the trusted setup, or assume the trusted setup was not compromised.
  • Fully validate Ethereum.
    • This includes downloading all state transitions.
    • Also includes verifying a validity proof for all rollup blocks. Individual state transitions do not need to be validated.

However, we must analyze the work users must do in the worst case, not the best case. In the worst case, the rollup block producers all go offline and the user must produce their own block. In other words, we must consider both state liveness and state safety, not only state safety.

To produce a new block, a user must re-apply every state transition in the rollup to get the latest state. This is actually the whole point of posting transactions to Ethereum! Notice that while the validity proof proves that a state transition is valid, it does not help at all in applying the state transition (which involves database reads and writes). In other words, the "succinct verification" property of validity proofs only applies to computation with no side effects, not state transitions.

Note: ZK rollups can only handle transfers and simple variants (such as multi-user transfer and swaps). This is because validity proofs operate on circuits rather than programs, and every possible execution path must be proved at all times. The cost of proving generic computation is intractable in practice, and has never been demonstrated to be viable.

As ZK rollups are limited to transfers, the only computation the validity proof can reduce is signature verification. However, this is not even remotely the bottleneck; modern processors can easily verify tens of thousands of ECDSA signatures per second with libsecp256k1. The bottleneck is actually state accesses. In other words, since they do not target the bottleneck, validity proofs in this context provide essentially zero scalability.


  1. Security is borrowed from the main chain, as rollup blocks are timestamped by Ethereum.
  2. ZK rollups are trust-minimized under the assumptions: 1) that the novel cryptography is sound, and has been implemented correctly despite immature tooling and few qualified auditors, 2) if a trusted setup is used, that the trusted setup was not compromised.
  3. Rollups are permissionless.
  4. ZK rollups will have higher throughput than Ethereum.
  5. Scalability is increased, as the data and execution model is much simpler than Ethereum.
  6. Additional concerns:
    • No need for hot keys.
    • Private key backup is sufficient to recover funds.
    • Novel cryptography must be audited by user, or trusted.
    • Capital efficient.
    • Latency cannot be lower than Ethereum, as rollup blocks are only valid once they are committed to Ethereum. ZK rollup blocks are immediately finalized once committed, however due to proof generation times take several minutes or more to be committed.
    • Anything but simple transfer are not possible on ZK rollups.

Optimistic Rollups

In optimistic rollups, each rollup block posted to the contract must be accompanied by the bond. Blocks are finalized after a timeout, at which point the bond can be recovered. The block posted as calldata must include both state transition information and witness data, unlike ZK rollups.

Anyone may post a fraud proof against a non-finalized block, causing the rollup chain to roll back to the previous block (and burning a fraction of the bond while rewarding the rest to the fraud prover). Therefore, on-chain finality requires waiting until the timeout expires. Valid blocks are guaranteed to finalize, however, so anyone may validate the rollup chain to get immediate finality for off-chain applications (e.g. accepting a payment, or performing an atomic swap).

Fungible tokens can be withdrawn immediately with atomic swaps between the rollup and Ethereum using a liquidity provider. Note that non-fungible tokens (NFTs) by definition cannot be liquid, therefore withdrawing NFTs from an optimistic rollup must wait the finalization timeout.

There is no inherent restriction on the execution model of an optimistic rollup, so long as a compact fraud proof can be produced, and verifying a fraud proof can be done within a single Ethereum block (modulo splitting up a fraud proof into several non-interactive steps). However, accounts-based execution models will have much lower scalability than Ethereum today.

This is because fraud proofs for accounts-based execution models require serializing the state after every transaction (or greatly increasing the size of transactions, rendering it strictly inferior to simply using the UTXO data model to begin with). Ethereum used to do this, but no longer does since serializing the state is, as the name implies, a sequential (serial) operation, and in general is a huge bottleneck for Ethereum today. The UTXO data model, in addition to parallel transaction validation, allows for fraud proofs without serializing state, resulting in greatly increased scalability.


  1. Security is borrowed from the main chain, as rollup blocks are timestamped by Ethereum.
  2. Optimistic rollup are trust-minimized under the assumptions: 1) 51% of miners are not censoring Ethereum for an extended period of time, and 2) there is at least one interested party that will submit a fraud proof if a fraudulent rollup block is committed (which could be the user themselves).
  3. Rollups are permissionless.
  4. Optimistic rollups may have higher throughput than Ethereum, depending on execution model.
  5. Scalability may be increased over Ethereum, depending on execution model. An EVM-based optimistic rollup will result in zero scalability improvements (and in fact scalability will be much worse). A UTXO-based optimistic rollup will be much more scalable than Ethereum.
  6. Additional concerns:
    • No need for hot keys.
    • Private key backup is sufficient to recover funds.
    • No novel cryptography.
    • Capital efficient.
    • Latency cannot be lower than Ethereum, as rollup blocks are only valid once they are committed to Ethereum. Valid optimistic rollup blocks are immediately finalized once committed, if clients validate them immediately (allowing immediate off-chain interactions, such as atomic swaps). Otherwise, the timeout to finality can be quite long (for on-chain interactions).
    • Virtually anything can be done in an optimistic rollup, so long as a compact fraud proof can be produced.

Interactive Verification Games

An alternative to fraud proofs is an interactive verification game, in which an interactive game bisects an execution trace until a difference is found. This bounds the maximum cost of a single step of this game to the cost of executing a single step of the trace, unlike fraud proofs where an entire transaction must be executed.

Beyond this distinction, there is little cryptoeconomic difference between optimistic rollups with fraud proofs and interactive verification games. Interactive verification games allow for more flexible execution models (e.g. a single transaction in the rollup that consumes 20 million gas), but result in lower scalability than using a UTXO-based execution model directly (or possibly even worse scalability than Ethereum) since a special virtual machine must be used to execute transactions off-chain. This virtual machine must be designed to have cheap individual operations, but is difficult to optimize for performance.

Note: In theory, an interactive verification game will be more robust against chain congestion attacks that fraud proofs. For example, if a fraud proof costs 9M gas to verify and the block gas limit is 10M, an attacker only needs to fill up blocks up to 1.1M gas to prevent fraud proof transactions from being included. Each step of the interactive verification game is very cheap, so an attacker would need to spam much more to block them from being included. In practice however, the cost of any individual fraud proofs should be intentionally low (less than 20% of the block gas limit or so), so there is no difference.

Note: When using fraud proofs, valid blocks are guaranteed to finalize, as they cannot be proven fraudulent. When using an interactive verification game, a valid block could be rolled back if a challenge on a valid block is intentionally lost. In practice this is not an issue as it requires unanimous participation to throw a challenge.

In summary, if more flexibility is absolutely required (e.g. single huge transactions that cannot be verified with a fraud proof), then an interactive verification game is a good idea. If not, a UTXO-based optimistic rollup with fraud proofs will be more scalable with no downsides.

Optimistic vs ZK Rollups

In terms of trust-minimization, users will have to make orthogonal trust assumptions for ZK rollups and optimistic rollups:

  • ZK rollups
    • that the novel cryptography is sound, and has been implemented correctly despite immature tooling and few qualified auditors
    • if a trusted setup is used, that the trusted setup was not compromised
  • optimistic rollups
    • 51% of miners are not censoring Ethereum for an extended period of time
    • there is at least one interested party that will submit a fraud proof if a fraudulent rollup block is committed (which could be the user themselves) These assumptions aren't directly comparable, so we cannot really say that one makes stronger assumptions than the other.

It may be tempting to say that miners can steal funds from an optimistic rollup but not a ZK rollup, but that ignores that layer-2 schemes do not exist in vacuo. If a majority of miners can censor Ethereum for an extended period of time, then they can also freeze user funds, which allows them to steal funds indirectly through blackmail.

Along the same vein, a common talking point in favor is ZK rollups is that a user can walk away for a decade and come back to their coins where they left them…but this is actually not true, even with ZK rollups! It is entirely possible that the layer-1 blockchain itself gets re-organized or otherwise mutated such that a user's funds in a ZK rollup–or even on the layer-1 chain–disappear. Decentralized blockchain are nothing more than mechanisms to facilitate social coordination; they are governed by people, not math or code. If a user does not actively watch the layer-1 chain (and the layer-2 with it) at regular intervals, then they cannot defend it–and their funds–from potential adversaries. In other words, regardless of what layer-2 scheme we use, we can assume that the base blockchain provides censorship resistance, because if not we must actively defend it in a timely manner.

In addition, we must consider the following facts:

In terms of scalability, as mentioned in the analysis of ZK rollups, the specific use of validity proofs provides no scalability. We must consider the worst-case failure mode of all the ZK rollup block producers disappearing or otherwise refusing to produce new blocks, at which point users must apply all state transitions themselves, for which the validity proofs do not help at all. Signature verification is not a bottleneck, so it's all a wash between validating signatures and verifying the validity proofs.

Validity proofs are useful for safe low-latency light clients, which fraud proofs cannot provide as their timeout must be long. This allows for immediate withdrawals (especially of NFTs) and composable interaction between a ZK rollup and other systems (similar to an atomic cross-shard transactions). However, since ZK rollups are limited to transfers and simple variations thereof, the practical usability of composable interactions is dubious.

In terms of on-chain efficiency (i.e. the marginal size of each transaction that must be posted as calldata), witness size for optimistic rollups is not a problem long-term. Rather than using per-transaction signatures, BLS aggregate signatures can be used instead, reducing the on-chain footprint of witness data to constant size per block. Interestingly, optimistic rollups are even more gas-efficient than ZK rollups, as the latter require the validity proof to be posted and verified as well.

To wrap up, the assumptions under which both optimistic rollups and ZK rollups are trust-minimized aren't comparable, and thus saying that one is inherently more trust-minimized than the other would be intellectually dishonest. ZK rollups provide zero scalability gains in practice over optimistic rollups, are more limited in their expressivity, are more expensive to use, and have higher latency-to-first-confirmation. On the other hand, optimistic rollups can only support immediate withdrawals of fungible assets, so they are cumbersome to use with NFTs.

In summary, if using NFTs is critical, then ZK rollups are the better choice. For everything else, UTXO-based optimistic rollups are superior: cheaper, lower latency-to-first-confirmation, more expressive, more scalable.

Rollup Mythbusting

Using PoS for block production is a good idea! False. Staking a token is worse-than-useless, as 1) we don't need a native token for security, since we're borrowing security from Ethereum, and 2) we can't implement a proper PoS protocol without hard forks, which cannot be done with a smart contract. A token simply adds costs and friction and provides nothing in return that cannot be done with ETH. Fuel does not have, and will never have, a "utility" token.

Rollup transactions are gas-free! False. Transactions in a rollup still require metering in order to prevent DoS attacks, and to ensure that invalid transactions are fraud-provable. If the execution model of the rollup is the EVM or some other generic VM, then rollup transactions will have to be metered similarly. Fuel currently meters transactions based on size (in bytes), as generic smart contracts are not supported at this time.

Note: The above exclamation is actually half-true. Rollup transactions do not have to pay ETH fees, as the rollup block producer is the only party that must interact with Ethereum to progress the rollup. Therefore rollups can be thought of as meta-transaction systems, allowing users to pay fees in any token the rollup block producers accepts.

Rollup transactions are free (as in "free beer")! False. Each rollup transaction has a marginal cost that must be paid by the block producer as calldata. If a rollup advertizes free transactions, then they are being subsidized from elsewhere–meaning someone else is overpaying fees. Fuel does not advertize transactions as being free.

Rollup transactions are instant! False. Rollup blocks must be posted to Ethereum, therefore a rollup cannot have a lower blocktime than Ethereum. Without a fully-collateralized bond, an adversary can double-spend transactions in an unconfirmed rollup block and guarantee a profit. A system with a fully-collateralized bond would end up as a channel. Fuel makes the explicit choice of not having a bond, since that would increase costs without providing any cryptoeconomic guarantees. Instead, our priority aggregator model allows the Fuel operator to promise an unconfirmed transaction will be included with high reliability, completely non-custodially.

EVM rollups can do {1000, 10000, 100000, A(4,3)} TPS with no downsides! False. EVM execution is the bottleneck for Ethereum. Throughput cannot be increased beyond the current ~15 TPS without a fundamental sacrifice elsewhere. This could be reduced decentralization with increased full node costs, or an additional trust assumption if users simply don't fully validate the rollup. Both are unacceptable in a scaling solution. Fuel uses a unique UTXO-based execution model that is much more scalable than the EVM, allowing for unparalleled throughput without changing decentralization. This does come at a cost for now: no generic smart contracts (which will be implemented in Fuel v2).

ZK rollups scale because you only have to verify a succinct proof! False. Validity proofs are useless for applying state transitions, which is by far the bottleneck in contemporary blockchain architectures.


Fuel's UTXO-based optimistic rollup is uniquely suited as the best scaling solution for Ethereum available today. It is trust-minimized and permissionless, and provides high scalability along with a number of other desireable properties, the particular combination of which is unmatched.

See Also

  1. Scaling Ethereum with Rollups at EthDenver 2020
  2. Fuel - A Trustless Scalable Sidechain at EthCC 2020
  3. Fuel: Scaling Ethereum with Optimistic Rollups at NonCon 2020