Original: “A Beginner’s Guide to Ethereum Censorship” by Donovan Choy
Compile: wesely
On August 8, 2022, the U.S. Treasury Department placed Tornado Cash on the sanctions list.
Everyone knows that regulators hate cryptocurrencies, but direct sanctions against DeFi took everyone by surprise, reflecting the efforts of U.S. regulators to crack down on cryptocurrencies.
Sanctions on Tornado aren’t all bad in a way, the regulatory shock reminded DeFi of its fundamentals and unlocked an onslaught of every centralized constraint in the decentralized finance landscape.
Core: Decentralization actually matters.
Any centralization shortcuts we take will be applied back to you.
The topic of censorship is hard to follow, some technical knowledge is required to understand Ethereum centralization, and Crypto’s ocean of terminology is inaccessible to many. This article attempts to debunk all the various censorship issues that Ethereum has encountered over the past few months, and try to demystify them in as plain language as possible.
I list each of the major centralized carriers of the Ethereum protocol and briefly describe the various technical solutions developers are working on.
A brief summary of the Ethereum supply chain
The original design of Ethereum theoretically involved only two participants:
-
A user running their own node, which will send a transaction over a peer-to-peer network to a block validator, who will then build a block and include that transaction.
-
Blockchain validators (we call them miners in PoW and stakers in PoS) are neutral participants who validate blocks.
In practice, the process is much more complicated. By selling blocks to searchers running arbitrage bots, validators can unfairly discriminate against packaged transactions, maintaining this incentive driven by profit. This leads to higher transaction costs and on-chain congestion, a phenomenon known as maximum extractable value (MEV). Over the past two years, MEV on Ethereum has reached $675 million (estimated at $6.7 million on Cosmos).
In the merged Ethereum, the MEV transaction sequence is as follows:
1. The user creates a transaction with the wallet through the front end of the dapp.These transactions are sent to the mempool
2. Seekers run arbitrage bots to scan mempools, then bundle transactions together
3. The bundled transaction is passed to the block builder, who then attaches a fee quote
4. If both the builder and the validator are connected to the relay, the relay will participate in the deblocking of the hidden bundle, which will then be offered for auction
5. Validators (AKA block proposers) choose fee bids and propose blocks
6. The prover certifies the block before it is finally on the chain
In this transaction order, the centralized carrier exists in each step, let’s sort it out from the beginning.
1. Front-end interface
Visit uniswap.com when you want to buy some ETH and see a well-designed pink/white UI that lets you easily navigate your trades. Connect to MetaMask, select the liquidity pool and click “send” to execute your trade. We take this simple process for granted, but many centralization threats have emerged in this segment.
Censorship Threats
Currently, the reality of many dapps’ front-end interfaces is centralization. The brief history of Web3 shows that DeFi tends to compromise when regulators come in. This happened when Balancer hid a $20 million liquidity pool from its frontend, and when Uniswap Labs quickly delisted dozens of synthetic assets on its frontend to avoid SEC scrutiny. MetaMask and Infura also block access to wallet addresses under Tornado Cash sanctions. (Recommended topic: “Tornado Cash caught in a regulatory “tornado””)
Crossing the front end is just the tip of the iceberg. The dapp we use relies on RPC nodes (servers) to communicate user needs, a node is a connection point, think of it as an API that can access information, communicate, and execute transactions on the blockchain.
In an ideal world, everyone would run their own node. But as Signal founder Moxie Marlinspike has criticized Web3, most people don’t run their own nodes, which creates a reliance on centralized node service providers like Infura and Alchemy. Their presence makes DeFi easier, but as you know, there are trade-offs. Since a large number of dapps such as Uniswap and Metamask in turn rely on Infura to run nodes, an important centralized carrier has emerged.
A centralized company like Infura, if targeted by regulators, could wreak havoc on Ethereum. Infura banned Iranian IP addresses in March to comply with U.S. political sanctions, and the issue with centralized node providers also has technical reasons. Ethereum experienced a network outage in November 2020, when Infura’s mainnet API made many dapps unusable due to its Geth client not being up to date.
Finally, the nodes need to be hosted somewhere. In fact, many Ethereum nodes are hosted on centralized cloud service providers like AWS, Hetzner, and Google Cloud (as are Solana and Bitcoin). The carrier of centralization here is obvious: cloud providers can stop server operations at will. The community was alerted in August when Hetzner clarified that running an Ethereum node on its servers violated its terms of service.
Source: ethernodes.org
Now and there are so many centralized carriers, but we haven’t gotten to the mempool yet.
Solution #1
Front-end centralization is an issue, but relatively minor. This is thanks to the thriving DeFi middleware ecosystem that allows us to bypass censored front ends in various ways. These include portfolio trackers like Zapper and Zerion, crypto wallets with integrated “Swap” functionality, and DeFi aggregators like 1inch and Paraswap. They allow you to access dapps without direct access. Most dapps like Uniswap have also committed to open source their front-end code, allowing any individual or DAO to recreate the front-end.
To bypass censored frontends, decentralized storage providers like IPFS are also used to host frontend domains with static content. For frontends with dynamic content (social media), decentralized indexing protocols like The Graph can query data across chains and dapps through a unified query language. For domain name censorship, decentralized name services like ENS offer a more censorship-resistant way to host domain names by building them on Ethereum smart contracts. This is unlike most websites today, which are stored on centralized DNS servers, which are subject to domain name seizures or IP address blocking.
Taken together, these decentralized infrastructure protocols lay the foundation for a decentralized Web3 economy on the DeFi front.
Solution #2
In solving the problem of node centralization, the key technical solution is the light client. The Ethereum Altair hard fork paved the way for them. These ultra-lightweight clients allow us to create our own native version of Ethereum on our own computer, mobile device or web browser, and we can broadcast transactions to any full node that accepts queries from the lightweight client Make a request. This way, dapps can also facilitate transactions instead of calling centralized RPC service nodes like Infura or Alchemy.
Light clients do not retrieve the entire beacon chain or set of validators. This is computationally intensive, they just sync block headers by knowing about peers. Crucially, this process is carried out through a randomly assigned group of validators (sync committees). The construction of the Beacon Chain PoS light client is also much simpler than the PoW light client. Only a few non-censoring full nodes are required to feed back these queries, which alleviates the problem of node concentration. More information on light clients can be found here.
Solution #3
As far as external node providers we rely on, there are decentralized alternatives to Infura, such as Pocket Network or Ankr, that minimize the need for Infura.
Recall that the problem here is that people lack motivation to run their own nodes. These RPC node providers introduce a set of economic incentives for this. In the case of Pocket Network, node providers pledge POKT to run blockchain nodes and relay data between different blockchains, serving dapps requesting on-chain data. In this permissionless market, the more relays they serve, the more POKT rewards they get. On the demand side, users/dapps also stake POKT, allowing it to request relays on the network. It should be noted that these projects also have points of centralization.
Source: Sami Kassab
Solution #4
The node hosting issue is a centralized risk that requires constant monitoring, but is less of a threat due to low barriers to exit. If AWS decides to limit hosting nodes on its cloud servers, node operators can easily migrate to a different cloud server without being locked in anywhere. Thanks to Merge, it is now easier to set up your own nodes with DIY hardware (Raspberry Pi) and a plug-and-play solution (Avado).
2. Searchers
When the user transaction is successfully submitted, the transaction will enter the mempool memory pool. The mempool is a database of pending transactions submitted by ordinary users, sometimes referred to as Ethereum’s “dark forest”, and MEV games start here.
Once transactions enter the mempool, searchers start scanning transactions for profitable MEV opportunities. Searchers are usually large institutions and proprietary trading platforms running arbitrage bots, but sometimes there are individual participants. They pay high gas fees to get validators to be the first to accept their transaction orders.
It’s worth noting that while MEVs are generally considered a bad thing, there are also good MEVs. For example, a DeFi protocol that needs to quickly clear lender collateral in the event of cryptocurrency price fluctuations wants to pay high gas fees to ensure that its transactions can be executed quickly. If the blockchain is designed on a first-come, first-served basis, then The efficiency of DeFi will be very low. Searchers play an important role in balancing this efficiency and building efficient blocks.
However, on the downside of MEV, while searchers are not a centralization risk themselves, they play a role in incarnating into giant centralized carriers by colluding with block builders. Their role in the protocol layer is to bundle transactions and pass them on to the next rung of block builders.
3. Block Builders and Validators/Proposers
Before Proposer/Builder Separation (PBS)
In pre-merger Ethereum, block construction was performed by miner entities, and miners were able to leverage the DEX for arbitrage and liquidation by distinguishing transactions in the mempool.
In this case, searchers and miners can collude in the underground market to maximize their own transactions for MEV arbitrage. This ultimately drives up the fixed cost of being a miner, as large mining pool operators have the capital to run complex algorithms, and the total amount of MEV withdrawn on Ethereum over the past two years has reached $675 million.
The centralization risk problem here is twofold: first, it hurts users who pay more transaction fees and transaction waiting periods; second, well-capitalized block validators are more capable of censorship due to political pressure.
In response, Ethereum developers are developing an in-protocol solution called Proposer-Builder Separation (PBS). As the name suggests, PBS splits the validator role into two separate local roles:
-
Proposers (i.e. validators who stake 32 ETH and build blocks)
-
builder
Under PBS, block builders compete with each other to create an aggregated ordered list of transactions from searchers. These transaction packages are optimized to maximize the builder’s own MEV fee, which is then passed on to the block proposer. Proposers select transactions based on their highest fees to create blocks and send them to the network’s main chain.
This reduces the centralized power of censorship by block proposers, since block builders do not choose which transactions contain the same person in the block. As Vitalik described in Endgame, the focus of PBS is to maximize the decentralization of validators.
But PBS is technically complex and takes years to be ready (maybe 2-8 years). The good news is that a temporary solution to the centralization of validators has emerged at the same time.
On the one hand, validators under Merge are randomly selected as block proposers in each slot. This is different from pre-merger PoW, where all miners compete to solve mathematical puzzles to validate new transactions. After one of the ~420K validators on Ethereum is randomly selected as a block proposer, another committee of validators is randomly selected to submit proofs (votes) about the validity of the proposed block. This double random shuffling layer is used to curb validator centralization on Ethereum, making it harder for attackers to censor or disrupt the network.
Second, projects like Flashbots have stepped in to manually create PBS. Flashbots have 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 effectively outsources the work of block building to a dedicated builder role. (Related reading: “Flashbots will launch SUAVE: The trade-off between censorship and decentralization”)
Why use Flashbot? Validators do this simply because staking rewards for them is more profitable. Flashbots’ software distributes MEV value more fairly between proposers and builders, rather than sharing it among large mining pools and searchers. What Flashbots do is stop this internal market of collusion between searchers and miners by creating a transparent, open market for price discovery. According to Hasu, using MEV-Boost has increased validators’ post-merge staking rewards by 135%.
Source: Flashbots
Note that MEV-Boost is optional, validators can still choose to build blocks themselves on their executing clients.
PBS removes the centralized power of large validators. But even after designing PBS, we haven’t lived up to the promise of decentralization. Centralized carriers, albeit with some relief, will still exist in a post-PBS world. The rest of this section briefly describes the various censorship threats that Ethereum faces and their corresponding solutions at work.
Censorship Threat #1
While PBS alleviates previous centralization problems, it also introduces new centralization problems at the builder level by giving the builder a higher ability to censor transactions. By creating a dedicated builder role, builders will be able to place high bids on blocks and exclude certain transactions.
Solution #1
The first solution is the Censorship Resistant List (crList) also known as “Hybrid PBS”. Suppose we suspect that the builder is trying to censor the transaction. We know this because the block they built for the proposer has not been filled and there are eligible transactions waiting in the mempool.
crList allows proposers to force builders to make full use of empty block space without requiring the proposer to dictate the order of transactions to include: “Hey builders, please fill in your empty blocks or the transactions I choose will be included. inside.”
Builders that insist on censoring transactions, and ignoring the proposer crList will have the block rejected by the prover (the prover is a randomly chosen validator who votes on the head of the canonical chain after the proposer proposes a block). In short, crLists are an indirect mechanism that allows proposers to control a centralized block-building market without defeating the original purpose of PBS (decentralizing proposers).
Solution #2
But what if the proposer could tell the builder to include the transaction, what if they colluded with the builder and told them? This brings us to the second solution: MEV-smoothing. Just as crLists control builders, MEV-smoothing controls proposers by removing their discretion.
The idea here is to ask the prover to focus on the deblocking market, specifically the fee bid attached to the block, and then only prove the block with the highest bid by the proposer. If the proposer doesn’t propose the most profitable block that has been built for them, then something happens, so the prover asks, “Hey proposer, do you just hate making money or do you want to censor?” Actually, MEV- Smoothing aims to equalize MEV profits for all proposers and create a fully efficient market that removes the incentive for proposers to engage in discriminatory scrutiny.
Solution #3
A third solution is to use crypto memory pools. While there are crLists counter builders and MEV smoothing counter proposers, crypto mempools are designed to counter both. This mechanism is easy to understand: it encrypts the content of user transactions and send/receive addresses before entering the mempool, and only decrypts when on-chain. This makes it difficult for participants to censor or engage in MEV extraction techniques such as transaction preemption. This eliminates the need for private memory pools like Flashbots, Protect. Crypto mempool technology is also something that Cosmos developers, privacy-oriented chains like Flashbot and Aztec are experimenting with.
Solution #4
The fourth and final solution is the one we least want to rely on, but it’s nice: altruistic self-build, where proposers simply choose to build their own blocks rather than outsource them to builders. The good thing here is that even with a small group of ~10% altruistic builders, Ethereum can keep going.
The obvious downside here is that it goes against the economic incentives, imagine validators want to use MEV-Boost because it generates higher fees, that’s why promoting a culture of resistance to censorship and maintaining decentralization at a social level is very important reason.
Censorship Threat #2
To be an Ethereum validator today, you need to stake 32 ETH in a deposit contract, running two software clients: an execution client (for executing transactions) and a consensus client (for newly produced blocks) reach a consensus). The threat today is that too many validators are running the same execution client Geth.
If a single client is found to be buggy or under attack, there is a risk of outages for the entire network. This is not theoretical speculation, as the 2016 Shanghai DOS attack demonstrated, the attack tricked the Geth client into slowing down processing. On the merged Ethereum, transactions are finalized requiring 2/3 of the ETH staked. A dominant client failure could temporarily halt or even fork the Ethereum network, making any validator running no more than 2/3 of clients critical!
The client centrality problem is so severe that even the most used client companies like Prysmatic Labs advise node validator users to use competitor validators. After all, if Ethereum goes down, it’s everyone’s loss.
solution
The threat of censorship here applies not only to individual stakers, but also to centralized node providers like Infura and Alchemy, or to decentralized node providers like Pocket Network. Solutions implemented by Ethereum developers include various penalties to slash the stake of inactive validators, such as inactivity leak mechanisms. On today’s Beacon chain, there are also associated penalties if misbehaving validators all fail on the same client, with harsher penalties for misbehaving validators. In effect, this promotes a multi-client culture while encouraging validators to consider not only technical risk but also economic incentives when choosing clients.
Censorship Threat #3
Finally, there is another threat of censorship that cannot be ignored: ETH is concentrated in staking services, and the two largest blocks are Liquid Staking Protocol and CEX, which control about 37% and about 31% of staking ETH. This is a serious problem, as any entity with more than 33% ETH can potentially conduct a double-spend attack.
Source: Dune Analysis
solution
There are no easy solutions here, but there are reasons to be optimistic. On the one hand, while Lido controls about 30% of the staked ETH, it does not exist as a single entity and has no direct impact on block construction. Lido’s ETH is passed through tens of thousands of nodes to 28 node operators, preventing any form of unilateral network attack.
But that’s still too little. A possible technical solution to the centralization problem of ETH is Distributed Validator Technology (DVT), also known as Secret Sharing Validator Technology, an area that the Ethereum Foundation has been actively researching since 2019. The company spearheading the development of DVT is RockX Lido, an institutional blockchain node provider (one of 28 node operators).
DVT is an open source protocol that spreads the operational activities of node operations among different validators, rather than a single validator. It uses a multi-party computation (MPC) process to ensure that nodes can be run by multiple validators because the private key is “shared”. Therefore, no single participant has full access to the private key needed to sign the message. This also allows a validator to replace another validator in the event of an infrastructure failure.
Lastly, while liquid staking protocols that hold too much ETH are very concerning, if instead of the Lido DAO, fully staking ETH on politically more vulnerable entities like Coinbase and Kraken, it would be worse than it is now .
4. Repeater
In the MEV-Boost model, the repeater acts as an intermediate broker, it sits between the proposer and the builder and can be easily started by anyone. The repeater is a unique centralized vehicle that is the product of Flashbot’s attempt to solve MEV. To understand the threat of censorship here, you first need to understand why repeaters are there.
Recall that the reason for wanting to split the validator role into proposers and builders under PBS is to curb the censorship power of the validators and prevent a situation where one entity (such as Coinbase or Lido) holds a large amount of staked ETH, the way It appears they can arbitrarily decide what to include on-chain.
Therefore, for PBS to work, proposers need to know nothing about the content of the blocks they receive from the builders. Otherwise, proposers will be able to distinguish blocks they think should be on-chain, and we’re back in the dark forest before.
This is where the repeater under Flashbots’ MEV-Boost model comes in. The builder sends a fee bid to assemble the block to the relayer, after which the relayer sends the block to a hidden escrow and only shows the price to any proposer’s payload accepted from that relay.
The block contents are only revealed after the proposer commits to sign the block header and accepts the bid. This way, proposers who want to review Tornado Cash transactions have no choice but to keep proposing blocks on-chain because they have already paid for it, or if they try to propose two blocks at a time, which will be blocked Cut penalties.
Source: Devcon Review Threats
But what if the relayers choose to censor themselves? This brings us to the heart of the centralization risk at the relayer level. Today, 58% of relay blocks on Ethereum are censoring Tornado Cash transactions, i.e. OFAC compliant. The majority (80%) of this 58% block came from Flashbots’ repeaters (see image below).
Note that there are many other validators still accepting blocks of Tornado Cash transactions, so this is actually a “soft” form of censorship that will appear after a few minutes, not a “hard” form of censorship. As long as the relayer has a non-censorship minority, this issue is an inconvenience to users, not what we traditionally think of as “censorship”. Still, the issue has led to a lot of attention to Ethereum censorship in recent months.
solution
The solution here is to encourage wider repeater diversity. Authenticators are usually connected to multiple repeaters at once. As shown above, three of the seven relays (BloXroute and Manifold) do not censor Tornado Cash transactions. Because the relay is a permissionless entity, anyone can easily create their own (Flashbots themselves have kindly open sourced their own). The low barrier to entry for creating censorship-free relays means that this centralization is lighter than at the validator level, where it is much more costly to block dishonest/misbehaving participants.
The good news is that relayers are a temporary censorship medium in the long run. When PBS is formally incorporated into the protocol, repeaters will no longer be required, as builders will be connected to proposers.
at last
Note that this post only covers the soft censorship form, which usually equates to block ingestion delays in seconds/minutes.
The article may not be exhaustive, more middleware protocols, such as oracles, sidechains and roll-ups, contain their own centralized carriers. Hard-hitting forms of censorship like 51% attacks, as well as technical and social solutions to them, are also excluded.