The cryptocurrency movement is built upon the foundational idea of censorship-resistance. Regardless of your identity, geographical location, or politics, you have the right to transact on the platform as long as you are willing to pay to do so. It is the only property that ultimately decides whether a cryptocurrency is truly decentralized and has the potential to put up a fight against nation state actors.

In the context of cryptocurrency, we can roughly define it as the following:

Censorship-resistance. A user generated transaction will be ordered for execution and eventually executed in a timely manner.

It is a simple definition and easy to digest idea. As long as can we guarantee a user’s transaction is eventually included in a block, then we have solved the problem.

Let’s take a look at layer-1 blockchains and validating bridges (rollups) to consider how censorship-resistance is upheld.

In cryptocurrencies like Ethereum, censorship-resistance relies on two assumptions.

• Single honest party. There must be at least one block producer who will include the user generated transaction in their block.

• Honest majority assumption. A majority of the block producers, by weight, will allow the fee-paying transaction to be included in the canonical blockchain.

To the pedantic reader, it is possible to subsume the single honest party within the honest majority assumption, but the separation provides clarity over the active role of including the transaction and the passive role of allowing the transaction to stay included. The crList proposal for PBS relies on the same set of assumptions.

As we have discussed in a previous article, the cornerstone of a Rollup is the Bridge contract. It is responsible for holding custody of the assets and enforcing the following three properties:

• State transition integrity. All state transitions (transaction) processed by the database are valid.

• Data availability. Anyone can fetch the data that is required to independently compute a copy of the rollup database.

• Censorship-resistance. A user can forcefully include their transaction to be ordered for execution.

Together, the bridge contract can enforce the correctness of the rollup database and ensure that an honest party can always withdraw their funds from the system, even if all rollup operator’s go offline.

Arbitrum was the first project to implement a censorship-resistance protocol for a smart contract-enabled rollup. It is a two-step process:

• Propose transaction. A user can post their transaction to the bridge contract and attach it to the list of “waiting to be ordered” pending transactions.

• Forced ordering. After a period of time, any user can force the list of “waiting to be ordered” pending transactions to finally be ordered for execution.

The two step protocol provides time for the sequencer to send a batch of transactions and guarantee it is ordered before the user’s submitted transactions. Once ordered, then any single honest party can eventually propose the final execution for all ordered transactions.

Unlike a layer-1 blockchain, there is only a single honest party assumption to enforce censorship-resistance in a bridge contract. Put another way, a user can single-handedly guarantee their transaction is eventually ordered for execution and ultimately executed.

There is an underlying theme for censorship-resistance for both layer-1 and layer-2 platforms.

As long as a transaction can be ordered for execution, then that is sufficient to guarantee a user’s ability to transact on the network. If we only considered platforms that supported payments (like Bitcoin), then perhaps it is true.

However, smart contract platforms like Ethereum have an interesting property:

Deterministic, yet unpredictable execution. A user can sign a transaction thinking it will result in State A, but the final execution is State B.

The execution of a user’s transaction ultimately depends on the state of a smart contract that is due to be executed on.

A user can have some control over the final execution by applying pre/post conditions which will simply fail the transaction’s execution if the conditions are not adhered too.

However, as we will see, the ability for a transaction to fail is the source of failure for censorship-resistance.

Maximal Extractable Value is the discipline of formalising and measuring the value that can be extracted by interfering with the execution of user-generated transactions.

The strategy is to take a user-generated transaction and evaluate:

• What is the range in which the target smart contract state can be changed and the transaction will still succeed?

• What transactions can the MEV’er include that will change the smart contract state and allow them to extract profit from the user’s transaction?

Over the years, we have witnessed MEV transition from priority gas auctions to sending transactions privately to the block producers. But in all cases, the strategies can include front-running, back-running or sandwiching a user-generated transaction. You can learn more about MEV strategies here.

Back in May 2021, I remember watching Vitalik Buterin dump his holdings of SHIBA tokens and effectively crash the price. It was really fun to watch. However, at one point, his transactions began to fail and he was temporarily unable to successfully transact on the network.

His transactions failed because MEV bots began to monitor his account and use MEV-strategies to front-run his transactions. This time, the goal was not to extract value from his transactions, but to guarantee they would always fail. He eventually overcame the issue by sending transactions directly to the block producer and bypassing the peer-to-peer network. I believe he used COW Swap.

But this helped lead me to an incredibly interesting insight:

Ordering is not enough: He could not rely on the guarantee that a transaction will always be ordered for execution. To protect his ability to transact, he had to rely on a single honest block producer to order the transaction and guarantee its final execution.

With MEV strategies in-mind, we can now go back to the censorship protocol implemented in Arbitrum. There are some points to consider:

• Force inclusion via bridge. A sequencer can ignore the user and force them to submit their transaction via the force inclusion mechanism in the bridge contract.

• Opportunity to study transaction. A sequencer can always review the user’s transaction in the bridge contract before sending their batch of transactions.

• Priority for ordering. A sequencer always has priority for ordering their transactions before and after a user submitted transaction.

• Single sequencer. There is only one sequencer in the system.

If we take the above points and apply it to the SHIBA censorship example, then we can see that Arbitrum’s sequencer can single-handedly censor the user’s transaction by forcing the transaction execution to fail.

How sequencer can fail tx (brief summary). The sequencer must ignore the user’s transaction and force them to submit it via the bridge contract. When it is in the bridge contract, the sequencer can sandwich it by submitting two batches of transactions. The first batch will be ordered for execution ordered before the user’s transaction and the second batch will be ordered for execution after the user’s transaction. The final transaction (in the first batch) and the first transaction (of the last batch) can change the smart contract state to fail the user’s transaction. Most importantly, there are plenty of applications where this involves little to no financial risk to the sequencer.

Even though Arbitrum can guarantee a user’s transaction will eventually be ordered for execution, it is still possible to prevent a user from executing their transaction by deploying MEV-like strategies. As such, it does not provide a strong guarantee of censorship-resistance if the sequencer is truly adversarial.

p.s. This is not to pick on Arbitrum’s attempt. It is one, if not the only smart contract-enabled rollup, that actually implements a censorship-resistant gadget for their rollup.

There are two ways to define censorship resistance:

• Enforced transaction ordering. Guaranteeing a transaction will eventually be ordered for execution.

• Enforced transaction execution. Guaranteeing that a transaction will be executed as expected by the signer.

Most protocols implement censorship-resistance as enforced transaction ordering, but in the face of MEV and express smart contracts, it appears not to be good enough to protect the user.

We really require a form of enforced transaction execution, or put another way:

The ability for one honest party to finalise the ordering of a transaction and be convinced that it will executed as expected.

In the SHIBA scenario, enforced transaction execution was guaranteed as the content of the transaction was privately disclosed to the block producer and they promised to include the transaction with the expected execution. By keeping it private, the attackers could not successfully interfere with its execution.

How do we solve enforced transaction execution in the general case? It may very well be that a rollup must host multiple sequencers and assume that at least one sequencer is honest. Another approach is to rely on a commit-reveal protocol to allow users to submit an unreadable blob for ordering and then to later reveal the content afterwards. Thus, preventing an attacker from interfering with its execution.

Regardless, I alluded to the idea that censorship-resistance remains the most understudied area for rollups and the takeaway is that this is indeed still the case. Most projects are so focused on data availability and state transition integrity, that they do not put much effort into protecting a user’s ability to ultimately transact.

This needs to change and it remains an open-problem for layer-2 rollups (and more generally, smart contract-enabled platforms). I hope this small insight helps with future iterations on censorship-resistance gadgets and someday a team will put together a real model on bridge contracts to uphold such a property.