A Beginner’s Guide to Ethereum Censorship
Dear Bankless nation,
Regulators are coming for crypto.
But DeFi is fine because it’s decentralized right?
Umm… no. Unfortunately, too many centralized vectors still exist.
And when regulators strike, that’s where they’ll be targeting.
If we want an Ethereum that works, we had first better understand what DeFi’s weaknesses are.
We did a podcast last month with Justin Drake detailing this. (📺 Watch it here!)
Today’s newsletter is a distillation of that pod into a 101 guide to understanding the censorship dynamics across Ethereum.
Donovan summarizes all the centralized chokepoints, and then how Ethereum is paving a path towards a censorship-resistant future.
Time to start building.
- Bankless team
On the 8th of August 2022, the U.S. Treasury sanctioned Tornado Cash.
Everyone knows regulators hate crypto, yet the sanctions took DeFi by surprise. It represented an unprecedented effort by American regulators to officially attack crypto.
In a way, the Tornado Cash sanctions were a blessing in disguise. The regulatory shock reminded DeFi of its fundamental principles and opened up scrutiny into every centralized chokepoint across the decentralized finance landscape.
Surprise, surprise: decentralization actually matters.
Any centralization shortcut you take can and will be used against you.
The censorship topic is hard to follow. Trying to understand the concerns around Ethereum centralization requires some technical knowledge, and the sea of crypto jargon is impossibly difficult to wade through.
This article is an attempt to demystify all the censorship concerns on Ethereum in past months, and distill them into easily understandable terms for any crypto citizen (or even haters!).
I lay out every major centralization vector on the Ethereum protocol, and briefly talk about the various market and technical solutions that entrepreneurs and developers are working on.
⛓️ A brief summary of the Ethereum supply chain
Ethereum as originally designed involved only two actors in theory: a user to run their own node that would send transactions over the peer-to-peer network to block validators that would build a block and include the transaction.
Blockchain validators (we call them miners in PoW, stakers in PoS) were supposed to be neutral participants validating blocks.
In practice, this process is much more complex. Validators face perverse incentives to discriminate by selling blocks to searchers who run arbitrage bots. This results in higher transaction costs and congestion on the blockchain for average users — a phenomenon known as maximal-extractable-value (MEV). MEV has amounted to $675 million on Ethereum in the past two years (estimated $6.7 million on Cosmos).
In post-Merge Ethereum, here’s the general transactional order:
Users create transactions with a wallet through a dapp’s frontend. These transactions are sent to the mempool.
Searchers run arbitrage bots and scan the mempool, then bundle up transactions
Bundled transactions are passed on to block builders, who then attach fee bids
If both builders and validators are connected to a relay, a relayer is then involved in concealing the bundled block before offering it up for auction
Validators (AKA block proposers) choose the fee bids and propose the block
Attestors attest to the blocks before it finally goes on-chain
⚠️ Note that the terms validators and proposers are used interchangeably in this article.
Centralization vectors exist at every step of the way in this transactional order.
Let’s examine them in order, starting from the frontend.
💁♂️ 1. Frontend interfaces
You want to buy some ETH. You go to uniswap.com, where a nicely-designed sleek pink and white UI awaits you to help you easily navigate your trade. You connect MetaMask, pick your liquidity pool, and click “send” to execute your trade. We take this simple process for granted, but already there are many centralization threats that surface on these intermediaries.
⚠️🛑 The censorship threat
The reality of many dapp’s frontend interfaces today is that they are centralized. Web3’s short history has shown that when regulators come knocking, DeFi answers the door. This happened when Balancer hid a $20M liquidity pool from its frontend, or when Uniswap Labs quickly delisted dozens of synthetic derivative tokens on its frontend to avoid SEC scrutiny. MetaMask and Infura have done the same to block wallet addresses in line with Tornado Cash sanctions.
Getting past the frontend is only the tip of the iceberg. The dapps we use rely on RPC nodes (servers) to communicate user intent. Nodes are a connection point – think of it as an API – that accesses information, communicates and executes transactions on the blockchain.
In an ideal world, everyone would run their own nodes. But as Signal founder Moxie Marlinspike once raised in a critique of Web3, most people don’t run their own nodes, which creates a dependency on centralized node service providers like Infura and Alchemy. They’ve made life in DeFi a lot easier, but as you know it, there are tradeoffs. Since a wide swathe of dapps like Uniswap and Metamask in turn rely on Infura to run nodes, a significant centralization vector has emerged on this end.
A centralized company like Infura, if targeted by regulators, would cause major disruptions to Ethereum. This in fact happened when Infura banned Iranian IP addresses to comply with US political sanctions in March. There are also technical reasons for why centralized node providers are problematic. Ethereum experienced such a network outage in November 2020 when many dapps became unusable after Infura’s mainnet API went down because its Geth client wasn’t up to date.
Finally, nodes need to be hosted somewhere. In reality, many Ethereum nodes are hosted on centralized cloud service providers like AWS, Hetzner and Google Cloud (as is true for Solana and Bitcoin). The centralization vector here is obvious: cloud providers can arbitrarily halt server operations. The community received that very reminder in August when Hetzner clarified that running Ethereum nodes on its servers was a violation of its terms of services.
So many centralization vectors, and we haven’t even gotten to the mempool yet.
Wut do?
💡 Solution #1
Frontend centralization is a problem, but a relatively small one. This is thanks to a burgeoning DeFi middleware ecosystem that lets us route around censored frontends through alternative venues in a variety of ways. Examples include portfolio trackers like Zapper and Zerion, crypto wallets with integrated “swapping” functionalities, DeFi aggregators like 1inch and Paraswap. They let you access dapps without having to visit them directly. Most dapps like Uniswap have also committed to open-sourcing the code of their frontends, allowing any individual or even a specialized DAO to recreate the frontend.
To skirt around censored frontends, decentralized storage providers like IPFS are also being used to host frontend domains with static content. For frontends with dynamic content (social media), decentralized indexing protocols like The Graph are used to query data across blockchains and dapps through a unified query language. And with censored domains, decentralized domain services like ENS provide a more censorship-resistant way to host domains by building them on Ethereum smart contracts. This is unlike most of today’s websites which are stored on centralized DNS servers, and therefore subject to domain name seizure or IP address blocks.
Put together, these decentralized infrastructure protocols make the foundational building blocks of a decentralized Web3 economy for DeFi frontends.
💡 Solution #2
In addressing the node centralization problem, the key technical solution are light clients. The Ethereum Altair hard fork paved the way for them. These ultra lightweight clients allow us to create our own sovereign, native version of Ethereum on our own computers, mobile devices, or web browsers, that we can broadcast transactions to and make requests to any full node that is accepting of light client queries. By doing so, dapps can facilitate transactions instead of calling a centralized RPC endpoint like Infura or Alchemy.
Light clients don’t try to retrieve the entire Beacon chain or validator set. That would be computationally intensive – hence why it’s called “light”! They simply sync block headers by knowing peer nodes. The key is that this process is performed trustlessly through randomly assigned groups of validators (sync committees). Beacon chain PoS light clients are also significantly simpler to build than PoW light clients. With just a few non-censoring full nodes that are answering these queries, node centralization problems are mitigated. For more on light clients, see here.
💡 Solution #3
Insofar as we want to rely on external node providers, there exist decentralized alternatives like Pocket Network or Ankr that minimizes the need for Infura.
Recall that the problem here is a lack of incentive for people to run their own nodes. These RPC node providers introduce economic incentives to do so. With Pocket Network for example, node providers stake POKT to run blockchain nodes and relay data between different blockchains, servicing dapps that request on-chain data. In this permissionless market, the more relays they serve, the more they earn in POKT rewards. On the demand side, users/dapps also stake POKT, allowing it to request relays on the network. Note that centralization points exist within these projects themselves, but there is a roadmap to removing them.
💡 Solution #4
The node hosting problem is a centralization risk that needs to be constantly monitored, but it is not a big threat because of low exit barriers. If AWS decides to restrict node hosting on their cloud servers, node operators can easily move to a different cloud server without being locked in anywhere. Thanks to the Merge, setting up your own node is even easier today with DIY hardware (Raspberry Pi) and plug & play solutions (Avado).
📡 2. Searchers
After user transactions have been successfully submitted, it enters the mempool, short for “memory pool”. The mempool is a database of pending transactions that have been submitted by users like you and I, sometimes referred to as Ethereum’s “dark forest 🌳”. It is here where MEV games begin.
Once transactions are in the mempool, searchers begin scanning the dark forest for profitable MEV opportunities. Searchers are typically big institutions and proprietary trading desks running arbitrage bots but sometimes also individuals. They pay high gas fees to get validators to accept their transaction orders instead of going through the public pool.
One thing to note here is that although MEV is typically talked about like it’s an exclusively bad thing, there is also good MEV. A DeFi protocol that needs to quickly liquidate a lender’s collateral amidst volatile crypto price swings wants to pay a high gas fee to ensure their transaction gets executed quickly. If blockchains were designed on a first-come-first serve basis, there would be extraordinary inefficiencies in DeFi. Searchers play an important role in evening out such efficiencies and constructing efficient blocks.
On the bad MEV side however, while searchers are not a centralization risk per se, they play a role in enabling a huge centralization vector by colluding with block builders. Their role in the protocol layer is to bundle up transactions and pass them to block builders in the next rung of the dark forest.
🏗️ 3. Block builders and Validators/Proposers
Before proposer-builder separation (PBS)
In pre-Merge Ethereum, block construction was performed by one entity: miners. This gave miners the power to capitalize on DEX arbitrage and liquidations by discriminating between transactions in the mempool.
Overtime, the problem got worse. Searchers and miners began colluding in an underground market to select most efficiently the transactions to maximize their own MEV profits. This eventually inflated the fixed costs of being a miner, as big mining pool operators with the capital to run complex algorithms outmatched your mom-and-pop miner – giving birth to what we know of as MEV. Total extracted MEV in the past two years has amounted to ~$675 million on Ethereum!
The problems of centralization risk here are twofold: first, it hurts Ethereum users who end up waiting longer or paying more on their transactions; second, well-capitalized block validators are in a much more able position to censor due to political pressure.
In response, Ethereum developers are developing an in-protocol solution known as proposer-builder separation (PBS). As its name suggests, PBS splits the validator role into two, separate native roles:
- Proposers (i.e., validators that stake 32 ETH and build blocks)
- Block builders
Under PBS, block builders compete against each other to create aggregated ordered lists of transactions from searchers. These transaction bundles are optimized to max out the builder’s own MEV fees, which is then passed on to the block proposer. Proposers are incentivized to select transactions based on the highest fees for themselves to create blocks and send it to the network to include on-chain.
The whole point of PBS is to reduce the centralized power of block proposers from censoring, as he/she who builds the block is not the same person selecting the transactions to be included in the block. As Vitalik describes in Endgame, PBS aims to maximize validator decentralization.
But PBS is technically complex, and won’t be ready for several years (perhaps 2-8 years down the road!). The good news is that interim solutions have emerged in the meantime to solve validator centralization.
For one, validators under the Merge are selected randomly to be block proposers in each slot. This is unlike under pre-Merge PoW where all miners compete in solving math puzzles to validate new transactions. After one of the ~420K validators on Ethereum has been randomly selected to be a block proposer, another committee of validators are randomly chosen to submit an attestation (vote) on the validity of the block being proposed. This doubled layer of random shuffling serves to curb validator centralization on Ethereum, making it harder for an attacker to censor or disrupt the network.
Second, companies like Flashbots 🤖 have stepped in to artificially create PBS. Flashbots developed a software client (MEV-Geth for PoW Ethereum, MEV-Boost for PoS Ethereum) that validators can simply plug into their consensus client and run on their nodes. This in effect outsources the job of block building to a specialized builder role (proposer-builder separation!).
Why use Flashbots? Validators do so simply because it’s more profitable in staking rewards for them. Flashbots’ software distributes MEV value more equitably between proposers and builders, rather than it being shared between large mining pools and searchers. What Flashbots does is to thwart this insider-collusion market between searchers and miners by creating a transparent, open market for price discovery. According to Hasu, using MEV-Boost has increased post-Merge staking rewards for validators by 135%.
Note that MEV-Boost is optional, and validators can still choose to build blocks by themselves on their execution clients.
In the PBS era
PBS removes the centralization power of large validators. But even after PBS is designed, we’re not at the promised lands of decentralization yet. Centralization vectors, albeit mitigated, will still exist in a post-PBS world. The rest of this section details in brief the various censorship threats Ethereum faces and its accompanying solutions in the works.
⚠️🛑 Censorship threat #1
While PBS mitigates previous centralization problems, it also introduces new centralization vectors at the builder level by giving them the heightened ability to censor transactions. By virtue of creating a specialized builder role, builders may be in a position to overbid for blocks and exclude certain transactions.
💡 Solution #1
The first solution is a censorship-resistance list (crList) or what is also referred to as “hybrid PBS”. Suppose we suspect that builders are attempting to censor transactions. We know this because the blocks they’ve built for proposers aren’t full, and there are eligible transactions sitting in the mempool waiting to be included.
A crList lets proposers force builders to fully utilize the empty blockspace, without enabling proposers to dictate specifically the order of the transactions to be included: “Hey builders, please fill up your empty block or my selected transactions will be included.”
A builder that persists in censoring transactions and ignores a proposer’s crList will be met with a rejection of the block by attestors (attestors are randomly selected validators that vote on the head of the canonical chain after proposing validators propose a block). In short, crLists is an indirect mechanism that lets proposers keep in check a centralized block building market without defeating the whole purpose of PBS to begin with (decentralizing proposers!).
💡 Solution #2
But if proposers can tell builders to include transactions, what if they collude with builders and tell them not to? This takes us to the second solution in the works: MEV-smoothing. Just as crLists keep builders in check, MEV-smoothing keeps proposers in check by removing their discretionary power.
The idea here is to ask attestors to pay attention to the block building market, in particular the fee bids attached to the blocks, then attest to only the highest-bidding blocks from proposers. If proposers aren’t proposing the most profitable blocks already built for them, something is up, so attestors ask, “Hey proposer, do you just hate making money or are you trying to censor?”
In effect, MEV-smoothing aims to equalize MEV profits for all proposers and creates a perfectly efficient market, removing the incentive of proposers to engage in discriminatory censorship.
💡 Solution #3
The third solution are the use of encrypted mempools. While crLists counter builders, and MEV-smoothing counters proposers, encrypted mempools are designed to counter both. This mechanism is easy to understand: it encrypts the contents of a user’s transactions and the sending/receiving addresses before it enters the mempool, and is decrypted only when on-chain. This makes it hard for actors to censor or engage in MEV-extraction techniques like transaction frontrunning . This removes the need for private mempools like Flashbots Protect. Encrypted mempool technology is something that Cosmos developers, Flashbots and privacy-oriented chains like Aztec are experimenting with too.
💡 Solution #4
The fourth and last solution is what we want to rely on the least but is a nice-to-have: altruistic self-building, where proposers simply choose to build their own blocks, rather than outsourcing it to a builder. The upside here is that Ethereum can continue chugging on even with a small minority of ~10% altruistic builders.
The obvious downside here is it runs counter to economic incentives – recall that validators want to use MEV-Boost because of its greater fee generation. This is why promoting a culture around censorship-resistance and preserving decentralization at the social layer is pretty important.
⚠️🛑 Censorship threat #2
To participate as an Ethereum validator today, you are required to stake 32 ETH in a deposit contract while running two software clients: an execution client (to execute transactions) and consensus client (to achieve consensus on newly produced blocks). The threat today is that too many validators are running the same execution client Geth.
This poses a higher risk of network outage should one client be found with a bug or suffer an attack. This is not theoretical speculation, as evidenced in the 2016 Shanghai DOS attack when attacks tricked the Geth client into slowing down processing. On post-Merge Ethereum, a supermajority of ⅔ of staked ETH is required for transaction finality. A dominant client malfunctioning could temporarily stall (or worse: split) the Ethereum network – which makes it critical for any given client to be running on no more than ⅔ of validator nodes!
So acute is the problem of client concentration that even the leading companies with the highest client usage like Prysmatic Labs recommend node validators to “use their competitors”. After all, if Ethereum goes down, it’s a loss for all.
💡 The solution
Note that the censorship threats here apply to not only solo stakers but also centralized node providers like Infura and Alchemy, or decentralized node providers like Pocket Network. Solutions that Ethereum developers have implemented include various punishments to slash the stake of inactive validators like the Inactivity Leak Mechanism. On today’s Beacon chain, there are also anti-correlation penalties that punish misbehaving validators more heavily if they all fail on the same client. In effect, this promotes a multi-client culture while encouraging validators to consider not only the technical risks but also economic incentives when choosing a client.
⚠️🛑 Censorship threat #3
Finally, it would be remiss not to mention another oft-mentioned censorship threat at the validator layer: the concentration of ETH in staking services. The two largest chunks belong to liquid staking protocols who control ~37% of all staked ETH and ~31% by CEXs. This a serious concern as any one entity with more than 33% of all ETH can engage in double-spending attacks.
💡 The solution
No easy solutions here but there are reasons to be optimistic. For one, while Lido controls a disproportionately high 30% of staked ETH, it does not exist as one single entity, and has no direct influence on block building. Lido’s war chest of ETH is passed onto 28 node operators who stake them through tens of thousands of nodes, preventing any kind of unilateral network attack.
Decentralization-maxi’s won’t find much comfort in 28 node operators, which is still far too few considering what’s at stake (the Ethereum network!). One technical solution that potentially addresses ETH concentration is distributed validator technology (DVT), also known as secret shared validator technology, an area that the Ethereum foundation has actively researched since 2019. The company spearheading development of DVT is RockX, an institutional blockchain node provider and one of Lido’s 28 node operators.
DVT is an open-source protocol that decentralizes the operational activities of node operations between different validators, rather than a single one. It uses multi-party computational (MPC) processes to ensure that nodes can be co-run by several validators because private keys are “shared”. Therefore, no one actor has full access to the private key needed to sign messages. This also allows validators to stand in for another validator in the event of infrastructure malfunction.
Finally, while liquid staking protocols holding too much ETH are extremely worrisome, it’s worth considering a counterfactual world where Lido DAO does not exist. In that world, ETH would be staked with even more politically vulnerable entities like Coinbase and Kraken, who already hold a large amount of ETH, a situation that would be far worse than the status quo.
🔌 4. Relayers
Relayers act as intermediary middlemen “brokers” sitting between proposers and builders in the MEV-Boost model that anyone can easily spin up. Relayers are a unique centralization vector that arose as a result of Flashbots trying to solve MEV. To understand the censorship threat here requires first understanding why relayers are in the picture at all.
Recall that the whole reason for wanting to split up the validator role into a proposer and builder under PBS was to curb the censorship powers of validators, and deter a scenario where one entity (e.g. Coinbase or Lido) that held a massive amount of staked ETH could arbitrarily decide what to include on-chain.
Therefore for PBS to work, proposers need to be in the dark about the contents of the blocks that they are receiving from builders. Otherwise, proposers would be able to discriminate between blocks that they think should be on-chain, and we’re back at square one before PBS.
That is where relayers come in under the Flashbots’ MEV-Boost model. Builders send an assembled block a fee bid to the relayer, after which the relayer sends the block to a hidden escrow and reveal only the price to any proposer accepted payloads from this relay.
Only after a proposer has committed to signing a block header and accepting the bid are the block contents revealed. This way, a proposer that wants to censor Tornado Cash transactions have no choice but to continue propose the block on-chain, because they’ve already paid for it, or be slashed if they try to propose two blocks at once.
⚠️🛑 The censorship threat
But what if the relayer themselves choose to censor? That takes us to the heart of the centralization risk at the relayer level. Today, 58% of all relayed blocks on Ethereum are censoring Tornado Cash transactions i.e., OFAC-compliant. The majority – 80% – of this 58% chunk comes from Flashbots’ relay (see below image).
Note that there are many other validators who are still accepting blocks with Tornado Cash transactions, so this really is a form of “soft” censorship that manifests in a delay of a few minutes, rather than a “hard” form of censorship. As long as relayers have a non-censoring minority, this problem will remain more of an inconvenience for users, rather than how we traditionally think of as “censorship”. Nonetheless, this is a problem that has led to widespread concern around Ethereum being censored in recent months (see here for more).
💡 The solution
The obvious solution here is to encourage a wider diversity of relayers. Validators are typically connected to several relays at once. As seen above, there are three of seven relays (BloXroute and Manifold) that do not censor Tornado Cash transactions. Because relays are a permissionless entity, that makes it easy for anyone to start their own (Flashbots themselves have open-sourced their own relay in good faith). The entry barriers to create a non-censoring relay is low, which means that this centralization vector is much less serious than if it were on the validator level, where it would be far more cost-prohibitive to deter dishonest/misbehaving actors.
The good news is that relayers are a temporary censorship vector in the long haul. When PBS is formally enshrined in-protocol, relayers will no longer be needed as builders will connect to proposers.
🦇🔊 In closing…
So there you have it. The entire MEV supply chain and what we’re doing about it. Feel free to add in the comments what I’ve missed.
Note that this article covers only soft forms of censorship, which typically amounts to a delay of block inclusion in seconds/minutes.
The article is not meant to be exhaustive — I have left out many more middleware protocols like oracles, sidechains and roll-ups that contain their own centralization vectors. Hard forms of censorship like 51% attacks, and the technical and social solutions to them also left out.