Fork-choice Rules and Reorgs

Fork-choice rules (FCR) describe how blockchain nodes establish confidence in the history of a chain based on subjective1 information. The simplest and best-understood rule is the proof-of-work rule: nodes must accept the history with the most accumulated difficulty.2 Nodes execute the fork-choice rule continuously as they learn consensus-relevant information. Each new block, attestation, or simply the passage of time may cause a node to update their subjective view of the chain tip according to some fork-choice rule.

Fork-choice rules are not objective evaluations of the chain tip. They rely on information that the node has observed, and are therefore always subjective. Nodes cannot enforce their FCRs be followed by other nodes, and at any given time, different nodes on the network may have different outcomes from the same FCR based on their individual subjective inputs. Trivially, this always occurs during block propagation. A block will have been accepted by some nodes, but not yet reached other nodes. As a result, the nodes will be on different histories, both of which are subjectively correct. As nodes observe new information, they update their view of the history according to their fork-choice rule. In a well-designed network (and in the absence of long-term partitions), nodes’ subjective views should converge over time. When nodes have consistent views of a chain’s history, we say they are “in consensus” with each other. Nodes following well-designed FCRs are eventually in consensus with other nodes.3

Ethereum has two officially-recommended fork-choice rules, one of which is also considered a fundamental protocol rule.4 First, attesters and proposers are expected to use a modified version of the LMD-GHOST5 rule to determine the canonical tip. Proposers should base their block on the tip chosen by the LMD-GHOST rule, and attestors should only sign attestations that confirm their subjective tip. Second, nodes are required to use the Casper FFG6 rule to finalize blocks. A node must not accept any history which removes a block after that block has been confirmed by their view of the Casper FFG rule. To conform to Ethereum protocol rules, nodes must follow the Casper FFG rule, but may deviate from the LMD-GHOST rule.7

Fork-choice rules allow observers (like nodes) to establish a view of the chain history, and therefore of the chain state. When this view changes in a way that rejects blocks previously accepted a chain reorganization (“reorg”) occurs. Nodes must unwind the execution of the blocks which have been decanonized, and execute blocks which have been canonized. The depth of permitted reorganization falls out of the design of the FCR. Some - like uncheckpointed PoW - allow reorganization of the entire chain, while others - like Tendermint and other “single-slot finality” FCRs - do not allow reorgs at all. While LMD-GHOST allows reorgs of unlimited depth, Casper FFG does not. Casper is mandatory. It is a violation of the protocol rules for a node to revert a block once finalized by its view of the Casper FFG FCR. Therefore rule-following Ethereum nodes currently support reorgs up to that depth.8

Fork-choice rules have a few secondary users. Light clients,9 for example, hypothetically follow an FCR without executing the state-transition function. More interesting, however, are rollups. Rollups, as users of the host chain, must follow some host FCR. Rollups, as chains, also have an FCR. Many desirable properties of a rollup derive from the relationship between host fork-choice and rollup fork-choice.

Reorgs are subjective, because FCRs are subjective. Because nodes have different clocks and views, some nodes may experience reorgs while others do not. For simplification, we say that the network experiences a reorg when a non-trivial fraction of nodes experience a reorg. This frequently removes individual blocks from the accepted history (preventing their Casper justification and eventual finalization), but very rarely removes more than 1 or 2 blocks. A reorg of depth 7 in 2022 was considered notable enough to prompt in-depth exploration. It would take a reorg of >= 32 blocks to remove the Casper-justified block. This should be considered a black swan event, and as a result justification is called “safe” by the node RPC.

Authors’ Note:

Throughout the remainder of this note, when we say “the host reorgs” or “the rollup reorgs” please interpret it to mean “when a significant number of host/rollup nodes accept a new history that is not a strict extension of previously accepted history after evaluating the fork-choice rule.” It is important to remember that reorgs are entirely subjective, but it’s very clunky to always use subjective language.

FCRs in Rollups

Much debate notwithstanding, rollups are blockchains. Their blocks form a neat chain, which nodes use to calculate the current state. Rollups have fork-choice rules. This may be a somewhat controversial statement. We’re too used to modeling rollups as dependent systems. However, it is a necessary consequence of rollups having blocks that form chains. There must be a process by which a node authenticates and accepts a new block. To the extent that the host chain affects the inputs to that process,10 the rollup must resolve history conflicts arising from host reorgs. We’ll first discuss the category containing all existing rollups: Host-following FCRs. We’ll then consider a second category with no concrete examples.

Host-following Fork-choice

All modern rollups are host-following. For host-following rollups, all rollup reorgs are triggered by a host reorg11 (although, this doesn’t mean that host reorgs always cause rollup sequence or state changes - more on this later). Host-following rollups include Arbiturm, Optimism, Taiko, ZkSync, and many others. Existing rollups can be sorted into two general types: Based and Run-ahead.12

Based (Totally host-following)

Based rollups follow the host fork-choice perfectly. For based rollups, every host reorg triggers a re-extraction of the rollup history corresponding to the affected host blocks. The new host history may contain different transactions and orderings, so as rollup nodes observe host reorgs, they re-derive the rollup sequence from the new host history. They then execute the rollup state-transition function on the new sequence to produce the new state,13 and discard the old sequence and state transitions. In this way, each host reorg directly causes a rollup reorg. 

Based rollups should be considered totally host following in that there is a bijective relationship: all host reorgs cause a reorg of the rollup, and all rollup reorgs are triggered by a specific host reorg. Based rollups have the simplest relationship to their host. Other systems introduce significant complexity.

Run-ahead (Partially host-following)

Run-ahead14 rollups muddy the fork-choice waters significantly. Run-ahead rollups - like Arbitrum and Optimism - assume that the Sequencer will not equivocate or falsify execution, and leverage this assumption to provide pre-confirmation of inclusion and pre-commitment to execution outcomes. Because the sequence is finalized before it is posted to the host chain, Ethereum reorgs often cannot cause a change to the sequence. The Sequencer’s commitment provides all necessary assurances to nodes that the sequence is immutable.

These run-ahead FCRs simply follow the Sequencer’s signatures, regardless of the host-chain’s behavior.  If the new host history omits previously committed rollup sequences, the rollup must reconfirm them, however, this does not imply a rollup reorg unless the sequencer equivocates. In order to support bridge-ins, the Sequencer references a specific host block in their batch commitment. The rollup sequence and the outcome of its state transition cannot change unless the referenced host block is replaced in the post-reorg host chain. Sequencers delay these host commitments for a security margin to ensure that these reorgs are uncommon.15

Compared to a based rollup, the sequence of a run-ahead rollup demands significantly more independence from its host’s FCR. Run-ahead rollup fork-choice rules should be considered partially host-following because all rollup reorgs are triggered by a specific host reorg, but not all host reorgs cause a rollup reorg. Which is to say, there is an injective relationship from rollup reorgs onto host reorgs.

Brief Digression

We discuss based and run-ahead rollups because they exist. We can imagine other examples of totally and partially host-following rollup fork-choice rules that are not strictly based or run-ahead. For example, consider a rollup using a lagging sequencer. In this case the sequencer orders a set of transactions after those transactions have been committed to the host chain. First, users commit transaction data in one epoch. In the next epoch the sequencer chooses an ordering for those transactions, and all nodes execute state-transitions.16 Ordering behavior could be invalidated if the host reorgs deeply enough to change transaction data in the commit epoch, leading to a reorganization of the rollup history. Which is to say, the FCR for this rollup would be partially host-following.

While there has been minimal exploration of rollup FCRs outside of run-ahead and based, at least we can examine some deployed examples of host-following rollups. Another major class of rollup fork-choice rules has not been explored at all.

Host-watching Fork-choice

Host-following fork-choice rules change their output only when the host chain FCR output changes. On the other hand, for host-watching fork-choice, only some rollup reorgs are triggered by a host reorg.  Host-watching fork-choice rules have conditions under which the rollup FCR  may reorg even though the host fork-choice rule has not reorged.17 This appears counterintuitive. We’re not used to thinking about rollup history as independent of host history. However, this is a host-centric view of the rollup history. 

While the rollup history must be derivable from the host history at any given point,18 rollups do not need to guarantee that that history becomes immutable at any point. Rollups have their own FCR. A rollup designer can choose a non-finalizing FCR, and a rollup engineer can write a node that respects such an FCR. There is no reason that rollup FCRs must be host-following. In fact the original Merged Consensus design, from which most modern rollup study descends, has a host-watching fork-choice. The design reorgs the rollup based on the state of the host in addition to the history of the host. Because it relies on contract state to enforce its FCR’s fault proof requirements, there are situations (valid fault proofs) under which the rollup may reorg in the absence of a host reorg.

Rollups can leverage reorgs to achieve interesting results. For rollups, updating the FCR means selecting a different sequence. Allowing the rollup to choose a new history effectively means reaching backwards in time to change things that have already occurred. Fork-choice extensions allow the rollup to enforce retrospective rules on its own history, state, and state-transitions. These rules may be evaluated at time t+1, but affect the outcomes of actions that occurred at time t by causing a reorganization of the rollup history.

(Small) Limitations

Like any fork-choice rule, the rollup FCR must rely only on information that the node can observe. In addition, rollups must be fully derivable from the host history. This imposes an additional constraint: rollup FCRs may only read information computable from the host history or state. This ensures that new nodes may still sync the rollup.19 This seems like a serious restriction, however it allows significantly more flexibility than it appears. Anything that can be submitted to host DA or produced by a smart contract can be used by the rollup FCR. This allows oracles, zk or fault proofs of any computation, DEX prices, and NFT ownership to be included in the rollup fork choice rule as long as they pass through the host history and/or state.

In addition, for rollups with bridges to the host chain, the bridge may not pass messages to the host until the rollup FCR has finalized the rollup history to a high degree of confidence. The FCR controls the inputs to the STF, which in turn controls the inputs to the bridge.20 As a result, if the FCR reorganizes the chain history, the bridge may have passed messages that are no longer part of the rollup history. That would be bad. The bridge from rollup to host must choose a subjective FCR and wait for it to be satisfied. This is the same constraint discussed with respect to light client bridges earlier, as ZK-proof and fault-proof bridges are simply a reified light client bridge.21

Examples

Reorganization of rollup history can be used to alter outcomes without altering transaction inclusion. Because the FCR defines the rollup’s history, it is allowed to edit it in any deterministic fashion based on any available information. It can insert arbitrary state transitions, transactions, state changes, hard forks, etc into the rollup’s history, even after many blocks have elapsed. The node must then evaluate the new history.22 The new history does not necessarily have to have any relationship to the old one, as long as it can be deterministically derived from host information. This shines in the presence of enshrined applications.

A simple and obviously useful example would be allowing a permissioned party to retroactively veto specific transactions on the rollup. It would be simple to set up as a specific event emitted by some host contract containing the transaction ID of the transaction to be removed. Upon observing such an event, a rollup node’s FCR would change the rollup’s tip to a new block whose history does not include the specified transaction. The nodes would unwind their local history to just before the transaction’s inclusion, and then re-execute all transactions except the specified transaction. This would allow an oracle to effectively “roll-back” hack transactions or other chain issues without a hard fork.23

Retroactive history changes seem broadly applicable.24 Application-specific rollups, or a general rollup willing to enshrine specific applications, could differentiate from applications hosted on general-purpose rollups by enshrining application semantics in the fork-choice rule. This would allow them to run application logic that extends across many transactions or blocks in ways that cannot be achieved by smart contracts alone.

Followup work

Optimization: Delayed State Commitment

Rollups whose FCR allows for retroactive history changes may want to delay committing to their state until the FCR guarantees finality as is done in other ecosystems.25 Rather than calculating a state root for sequences which may be reverted, they could instead delay calculation of that root until the protocol rules out reorgs. This would save a significant amount of calculation on each reorg,26 allowing deeper reorgs with the same computational resources. However, delayed commitment would marginally delay fault- or zk-proof based bridges. Given the complex trade-offs and that the chief benefit here is optimization, it seems like significant more examination would be warranted.

Multi-host-following/watching Rollups

A rollup has its own fork-choice rule, which it can extend in arbitrary ways. Why not introduce the fork-choice rule of a third chain? This would allow the rollup privileged communication with that chain. This has been loosely explored before and at first appears to create serious synchrony issues. Nodes following independent chains may have completely different views of the FCR outcome for each chain, and those views may diverge forever. However, we can use the same trick as applications to get access to information outside the host. We can simply pass information through the host. 

Rather than watch the third chain directly, we can introduce an evaluation of the third chain’s FCR into the host chain’s state or history via a smart contract. The rollup FCR can read the result of this smart contract execution. In this way, the rollup’s FCR has access to any bridge which the host chain has access to. While this seems to solve the problem, it does introduce some amount of time lag. The delay to communicate to the rollup from the third chain is increased by the finalization period of the host bridge’s FCR for the third-chain.27 This feels bad. There may be ways to improve this without integrating the third chain’s FCR into the host FCR. It may be possible to use contingent states or some other local-verification solution to speed this up and prevent the wait. More research is needed.

Conclusion

Rollups are real blockchains. They have their own nodes, fork-choice, and state. Rollups can reach backwards in time and edit their own history and state. By carefully choosing their fork-choice rules rollups can achieve fast communication with the host and allow their applications to modify the history of the chain in useful ways. There are clear use cases for FCR-enshrined applications for hack-reversion, censorship, and fair execution guarantees. Rollup FCR research has been chilled by the over-complex design of run-ahead sequencing and the over-simplistic design of based sequencing. Rollups using run-ahead or based sequencing are giving up a significant edge over competitors.

Subscribe now

Censorship resistance remains a core value of cryptocurrencies in general, and Ethereum in particular. We believe that the benefits of transacting on-chain should be available to anyone, and that the rules of the chain should apply to all users and uses equally. Values drive this space forward. Engineering is the process of testing our values against reality to find where and how they break.

Defining Censorship

We tend to model censorship as intentionally preventing transactions from appearing in the canonical ordering (i.e. transaction exclusion). We consider orders to be fair or neutral when they depend entirely on the economic outcome for the ordering system, and unfair or censored when they depend on other information. E.g. when creating a block, it is acceptable to refuse to include a low-fee transaction, but unacceptable to refuse to include a transaction because it was sent by a specific person. Therefore, we say a transaction is censored if its inclusion depends on non-economic information. If the transaction creates more observable profit for the ordering system than any included transaction, but is not itself included, it is considered to be censored. This definition motivates work on forced inclusion mechanisms for censorship resistance. If a user can force the inclusion of their transaction, then it cannot be censored under this definition.

Forced Inclusion Mechanisms 

A core security goal of OP Stack chains is that the Sequencer should not be able to prevent users from submitting transactions to the L2 chain. 

- Optimism

Modern rollups tend to have centralized sequencing. This means that censorship by the sequencer is trivial, as they can simply choose not to include any given user transaction. To mitigate this, several rollups - including Optimism and Arbitrum - have forced inclusion mechanisms. These mechanisms allow a user to ensure that their transaction will be executed by the rollup after some time delay, regardless of the sequencer’s behavior. Inclusion is forced via a contract deployed on L1. Forced inclusion transactions therefore (theoretically) have the same resistance to censorship as other Ethereum transactions.

A forced inclusion mechanism has also been proposed for Ethereum via EIP-7547. Inclusion lists would allow block proposals to partially specify the contents of the next block. Under the assumption that block proposers have fewer incentives to censor than block builders, it would provide an effective mitigation to censorship.

Generally speaking, forced inclusion mechanisms create new constraints on valid orderings. They make broad classes of orderings invalid according to protocol rules1. Forced inclusion should be thought of as allowing the user to specify a subset of the future ordering. All valid orderings must expand upon the forced subset. 

Expanding Our Model of Censorship

Unfortunately, transaction confirmation is the means, not the end. Our model of censorship is incomplete!

Censorship must be defined in terms of goals. Users want to send tokens, buy NFTs, borrow funds, etc etc. The transaction’s confirmation is incidental to that goal2. Censors, similarly, have specific goals. That goal may be to prevent some hack transaction from succeeding, to comply with some law, or to interfere with a competitor’s business. Respecting the intent of both parties, we need to redefine censorship.

With this in mind, we should expand our definition of censorship to say: a transaction is censored if a third party can prevent it from achieving its goal. Which is to say, the censor does not need to prevent the transaction from confirming; they only need to make smart contract execution revert. Making an EVM transaction revert is censorship of that transaction, despite that transaction being part of the canonical chain. Threat models that are blind to the contents of a transaction do not accurately model censorship, and therefore cannot effectively protect users from it.  

Semi-formally, we would say that for any given interaction with the chain, there is some scoring predicate f that evaluates the resulting ordering, and produces 0 (goal failed) or 1 (goal achieved). In this model, the censor’s scoring function is simply the negation: f’ = !f. The censor achieves their goal when the user does not.3 

While the user’s goal may be hidden, the transaction itself almost always contains enough information to infer it. Uniswap trades have obvious goals. In addition, because blockchains are deterministic, the censor can perfectly predict which orderings will satisfy the censor’s predicate. As a result, users cannot rely on hidden information to protect them from censorship in the EVM model. Transaction details must be public, which means that information about the user’s goal is public.

For simplicity, let’s assume that we’re working in the standard run-ahead sequencer model4. We will deal with the forced inclusion under sequencer rotation later. In this model, the sequencer has total control over the sequence, and can perfectly simulate any outcome. Which is to say, they are free to choose from the set of all possible orderings. Our semi-formal question about censorship then becomes “does there exist some valid ordering over which f evaluates to 0”? If such an ordering exists, then the sequencer can select it.

From there, we can expand our model to account for forced inclusion. “Does there exist some valid ordering, which includes the user’s sub-ordering, for which f evaluates to 0?” If such an ordering exists, the sequencer can select it. Forced inclusion does not prevent the sequencer from exercising control over the ordering, it only constrains their behavior. Unfortunately, forced inclusion has fundamental issues that prevent it from being an effective censorship resistance mechanism for many transactions.

The Hand-off Problem

Forced inclusion mechanisms mean ordering happens in one of two modes: unforced or forced. There is a defined point at which it transitions from unforced to forced (and vice versa). That point is the hand-off. The hand-off poses a thorny issue for the design of forced inclusion mechanisms.

The forced transaction executes on the state at the hand-off. So once again, state contention5 rears its ugly head. When the hand-off occurs within a batch of transactions (like a block), the creator of the batch can exercise control over the state at the hand-off. If the forced inclusion transaction reads any public state, then the creator of the batch can rewrite that state before and after the forced transaction execution. Contention is sufficient for censorship.

Because the batch creator can exercise control over the state at the hand-off, then it can affect the outcome of the forced transaction. If it can affect the outcome, it can potentially affect the result of the scoring predicate. For example, consider a simple AMM interaction. The user sets a minimum acceptable price, however, the batch creator can ensure that at the handoff point the market price is below the minimum acceptable price. This causes the user transaction to revert, effectively censoring the user.67

Interestingly, censorship via state contention is more effective than censorship via exclusion. An excluded transaction can be included in future blocks. A transaction censored via contention is permanently invalidated. It has been included in the chain, and can never be included again. That transaction can never achieve the user’s goal. To try again, the user must recreate and resubmit the transaction (which can then be potentially censored again). 

In practical systems

[A]ny user can bypass the Sequencer entirely to submit any Arbitrum transaction (including one that, say, initiates an L2 to L1 message to withdraw funds) directly from layer 1. Thus [sic] mechanism thereby preserves censorship resistance even if the Sequencer is being completely unresponsive or even malicious.

- Arbitrum

In the run-ahead sequencing model, the sequencer has near-perfect control over the location of the handoff in the sequence, and pays reduced fees (as they need not tip and can exercise some control over the EIP-1559 basefee). As a result, the sequencer is in a privileged position to use state contention to censor user actions. It is trivial. The hand-off problem ensures that the sequencer can censor large classes of transactions.

For EIP-7547, builders choose where in the block hand-offs occur.8 As a result, the builder is capable of choosing the location of the hand-off within the block. This means that they can select a prefix and a postfix at will,9 as long as they respect block gas rules. The prefix can put the chain into a state on which the transaction will revert, while the postfix will restore the chain to a normal state. EIP-7547 inclusion lists are not sufficient to prevent censorship for any transaction accessing contentious state. The hand-off problem prevents ILs from ensuring transaction execution in most cases.

Forced inclusion is ineffective at protecting users from censorship for most non-trivial uses of the blockchain. The hand-off problem ensures that the censor has sufficient discretion over state even if they don’t have sufficient discretion over order. This problem affects AMMs, lending markets, auctions, and most other DeFi actions. Many important actions are censorable even if you can guarantee transaction inclusion. State contention creates hard limits on the effectiveness of forced inclusion as a censorship-resistance mechanism.

Case study

To see the far-reaching effects of this, consider a user lending USDC in a lending market on Optimism. When the user wants to withdraw USDC from the market, they submit an Optimism transaction, which the sequencer censors. They then use the official forced inclusion mechanism to queue their transaction on Ethereum, bypassing the sequencer.

The sequencer can see that transaction in the queue, and can choose to sandwich it. In order to censor the transaction, the sequencer borrows all available USDC from the market immediately before the forced transaction. Because the market no longer has liquidity, the forced transaction reverts. The sequencer can then repay the USDC immediately.

This requires the sequencer to have collateral sufficient to borrow the USDC, but it imposes only an extremely small borrow cost.10 Furthermore, the collateral is reusable for all censorship, as the borrow is never held open. As a result, a user of AAVE or Compound on Optimism (or Arbitrum or any other centrally-sequenced rollup) has no guarantee that they will be able to withdraw collateral ever. The sequencer can censor any withdrawal from any lending market at any time. Forced inclusion is simply not sufficient to protect users against censorship.

Followup Work

We have a few areas of followup research.

First, EIP-7547 can be trivially improved by requiring IL transactions be processed at the end of the next block. In the PBS auction context, censorship is MEV. The builder derives some non-economic value, to which they must assign a subjective value denominated in ETH. Censorship by the builder therefore causes an increase in the builder’s block bid.11 This extends to searchers, who may make censoring bundles. Some of the economic value of censorship is then captured by the proposer, providing an incentive to tolerate censorship even when not participating in it directly. Placing forced inclusion transactions at the end of the block removes the block builder’s ability to trivially sandwich the IL transactions, and increases the economic cost of contentious censorship. E.g. censoring an AMM interaction via state contention could require giving up some AMM arbitrage or a high cost to push the market out of range that cannot be recouped by closing the sandwich. In addition, this would restrict censorship bundles produced by Searchers (rather than builders) to one per block.12 We would recommend top-of-block execution, as the prefix is more significant than the postfix, however, that would drastically increase the cost of an IL transaction, as it would allow top-of-block MEV extraction via forced inclusion.13 Removing the censor’s right to atomically postfix the IL transactions is a small improvement.

Second, the hand-off problem exists because the censor can look ahead via transaction simulation and exercise control over the input state. Many MEV-resistance mechanisms introduce hidden information to remove the censor’s ability to derive information about users’ goals and to simulate outcomes. Typically these are commit-reveal schemes, where some transaction information is private until after ordering occurs. Ordering-execution separation and hidden information seem promising, but are largely incompatible with the MEV supply chain, Ethereum consensus processes, and the sequenced rollup model. Some way to negate the ability to simulate transactions would address censorship and large classes of MEV, but would be extremely invasive to the protocol, the operators of the protocol, applications, and the end user.

Third, there is an interesting class of “order-independent” scoring functions. These are goals that cannot be censored by state contention, either because they don’t access contentious state, or because the contentious state they do access has sufficient constraints to make it “reliable” in some sense. Order-independent actions include sending ETH to an EOA, most ERC-20 sends,14 and some DeFi interactions like adding collateral to a market. These actions are protected from censorship via contention. This class of goals also has interesting correspondences in safe cross-chain communication and MEV resistance and is worth more in-depth study. Applications and protocols may be designed to include only order-independent actions in some cases, but more study is needed.

Conclusion

Rich state allows malicious actors to censor transactions while still including them. The hand-off problem is fundamental to forced inclusion mechanisms, and can only be mitigated. In centrally sequenced rollups, no mitigation is possible. Forced inclusion cannot address censorship in the presence of contentious state. Large classes of economically important transactions can be censored, even if included by force. The hand-off problem is endemic in modern rollups, and present in Ethereum’s censorship resistance EIPs. As a result, forced inclusion, while beneficial, is never sufficient to provide censorship resistance for rich-state chains. Rollups do not “inherit” Ethereum’s security properties and it’s silly to suggest that they do. When you stop obsessing over inclusion, it becomes obvious that censorship resistance is a special case of MEV resistance.

We’d like to thank Mike Neuder, Tarun Chitra, and Brandon Curtis for review and feedback.