Originally Posted by Donovan Choy, Bankless Contributor
Original Compilation: Zion, CT Chinese
Ethereum is yet to achieve censorship resistance...here's what developers are doing.
On August 8, 2022, the U.S. Treasury Department sanctioned Tornado Cash.
Everyone knows regulators hate cryptocurrencies, but this sanction has caught DeFi off guard. It represents an unprecedented effort by U.S. regulators to formally crack down on cryptocurrencies.
In a way, the sanctions against Tornado Cash were a blessing in disguise. This regulatory onslaught reminded DeFi of its fundamentals, launching a scrutiny of every centralized checkpoint in the entire decentralized finance space.
Decentralization actually matters.
Any shortcut you take to centralization can be used against you.
The topic of censorship is difficult to understand. Trying to understand the concerns surrounding Ethereum centralization requires some technical knowledge, and the ocean of crypto jargon is difficult to navigate.
This article attempts to demystify all of Ethereum’s censorship issues over the past few months and distill them into terms that any crypto citizen (even a hater) can easily understand.
I list every major centralization vector on the Ethereum protocol and briefly describe the various market and technical solutions that entrepreneurs and developers are working on.
A brief overview of the Ethereum supply chain
Ethereum's original design theory involved just two participants: users running their own nodes, sending transactions over a peer-to-peer network to block validators, who would build a block and include the transaction.
Blockchain validators (we call them miners in PoW and stakers in PoS) are supposed to be neutral actors validating blocks.
In reality, the process is much more complicated. Validators face perverse incentive discrimination by selling blocks to seekers running arbitrage bots. This leads to higher transaction costs for ordinary users and congestion on the blockchain — a phenomenon known as Maximum Extractable Value (MEV). Over the past two years, MEV on Ethereum reached $675 million (estimated at $6.7 million on Cosmos).
In the merged Ethereum, the following is the general order of transactions:
Users create transactions with wallets through the dapp's front end. These transactions are sent to the memory pool (mempool);
Searchers run arbitrage bots and scan mempools, then bundle deals together;
Bundled transactions are passed to block builders, who then attach fee bids;
If both builders and validators are connected to a relayer, the relayer will hide the bundled blocks before submitting them to the auction;
The validator (i.e. block proposer, proposer) selects the fee bid and proposes the block;
Attestors validate the block before it is finally put on the chain.
(Note that the terms validator and proposer are used interchangeably in this article.)
In this transaction sequence, there is a centralization vector at each step.
first level title
01. Front-end interface
secondary title
censorship threat
Today, many dapps have centralized front-end interfaces. The short history of Web3 shows that when regulators come knocking, DeFi answers. This happened when Balancer hid a $20 million liquidity pool on its front end, or when Uniswap Labs quickly delisted dozens of synthetic derivative tokens on its front end to avoid SEC scrutiny. MetaMask and Infura have also taken the same step to block wallet addresses that comply with the Tornado Cash sanctions.
Getting over the front end is just the tip of the iceberg. The dapp we use relies on RPC nodes (servers) to communicate user intent. A node is a connection point (think of it as an API) that accesses information, communicates, and executes transactions on the blockchain.
In an ideal world, everyone could run their own node. But as Signal founder Moxie Marlinspike once pointed out when criticizing Web3, most people do not run their own nodes, which creates a dependence on centralized node service providers such as Infura and Alchemy. They have made life in DeFi a lot easier, but as you know, it comes at a price. Since a large number of dapps such as Uniswap and Metamask in turn rely on Infura to run nodes, a significant centralization vector emerges at this end.
A centralized company like Infura, if targeted by regulators, would cause significant disruption to Ethereum. In fact, this happened when Infura banned Iranian IP addresses in March to comply with U.S. political sanctions. There are also technical reasons why centralized node providers are problematic. Ethereum experienced a network outage in November 2020, when Infura's mainnet API was paralyzed because its Geth client was not updated, and many dapps were unavailable.
image description
Source: ethernodes.org
With so many centralization vectors already, we haven't even talked about mempools yet.
secondary title
Solution #1
Front-end centralization is a relatively minor issue. This is thanks to the thriving DeFi middleware ecosystem, which allows us to bypass the censored dapps front end through alternative venues in various ways. Examples include portfolio trackers like Zapper and Zerion, crypto wallets with integrated “exchange” functionality, and DeFi aggregators like 1inch and Paraswap. They allow you to access dapps without direct access. Most dapps like Uniswap are also committed to open-sourcing their front-end code, allowing any individual or even a dedicated DAO to re-create 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 are used to query data across blockchains and dapps through a unified query language. And for censored domain names, decentralized name services like ENS offer a more censorship-resistant way to host domain names by building domain names on top of Ethereum smart contracts. This is unlike most websites today stored on centralized DNS servers, which are vulnerable to domain name seizure or IP address blocking.
secondary title
Solution #2
For 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-light clients allow us to create our own sovereign, native version of Ethereum on our own computers, mobile devices, or web browsers, where we can broadcast transactions to any full node that accepts queries from the lightweight clients and Make a request. By doing this, dapps can facilitate transactions instead of calling centralized RPC endpoints like Infura or Alchemy.
secondary title
https://twitter.com/SalomonCrypto/status/1579283196708941824
Solution #3
When we want to rely on external node providers, there are some decentralized Infura alternatives like Pocket Network or Ankr that minimize the need for Infura.
image description
secondary title
Solution #4
first level title
02. Searchers
After the user's transaction is successfully submitted, it will enter the memory pool. The mempool is a database of pending transactions submitted by regular users like you and me, sometimes referred to as Ethereum's "dark forest🌳. The MEV (Maximum Extractable Value) game starts here.
Once transactions are in the mempool, searchers start scanning the dark forest for profitable MEV opportunities. Searchers are usually large institutions and proprietary trading desks running arbitrage bots, but sometimes include individuals as well. They pay high gas fees for validators to accept their transaction orders instead of going through the public pool.
One thing to note here is that while MEVs are generally considered to be all bad, there are good MEVs as well. In the case of volatile cryptocurrency prices, the DeFi protocol needs to quickly liquidate the lender's collateral, and it needs to pay high Gas fees to ensure that the transaction can be executed quickly. If blockchains were designed on a first-come, first-served basis, DeFi would be very inefficient. Searchers play an important role in balancing this efficiency and building efficient blocks.
first level title
secondary title
1) Before Proposer Builder Separation (PBS)
Before the Ethereum merger, block building was performed by one entity: miners. This allows miners to take advantage of DEX arbitrage and liquidation by differentiating transactions in the mempool.
The problem gets worse over time. Seekers and miners begin to collude in the underground market to select transactions most efficiently to maximize their own MEV profits. This ultimately drives up the fixed costs of being a miner, as large mining pool operators have the capital to run complex algorithms, outpacing home-run miners — giving birth to MEV as we know it. The total amount of MEV withdrawn on Ethereum over the past two years has reached $675 million!
The centralization risk here has two problems: first, it hurts Ethereum users, who end up waiting longer or paying more transaction fees; in a more favorable position.
To combat this, ethereum developers are working on an in-protocol solution known as proposer-builder separation (PBS). As the name suggests, PBS splits the validator role into two separate native roles:
block builder
block builder
Under PBS, block builders compete with each other to create an aggregated ordered list of transactions from seekers. These transactions are bundled together and optimized to maximize the builder's own MEV fees, which are then passed on to block proposers. Proposers are incentivized to select transactions based on the highest fees to create blocks and send them to the network to be included on-chain.
This reduces the centralized power of block proposer censorship, since the people who build the block are not the same people who choose the transactions to be included in the block. As Vitalik wrote in "The Endgame of Blockchain ExpansionAs described in the article, the whole point of PBS is to maximize the decentralization of validators.
But PBS is technically complex and won't be ready for a few years (maybe 2-8 years later!) The good news is that interim solutions to validator centralization have emerged in the meantime.
First, the merged validators are randomly selected as block proposers in each slot. This is different from pre-merger PoW where all miners validated new transactions by solving mathematical puzzles. After one of the approximately 420,000 validators on Ethereum is randomly selected as a block proposer, another committee of validators is randomly selected to submit proofs (votes) of the validity of the proposed block. This dual layer of random shuffling works to curb validator centralization on Ethereum, making it harder for attackers to censor or compromise the network.
Second, companies like Flashbots have stepped in to artificially create PBS. Flashbots has 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 building blocks to a dedicated builder role (separate proposers from builders!)
Source: Flashbots
Source: Flashbots
secondary title
2) Proposer/Builder Separation (PBS) Era
PBS removes the centralized power of large validators. But even after PBS was designed, we haven't arrived at the promised land of decentralization. In the post-PBS era, the centralization vector, while lessened, will still exist. The remainder of this section provides a brief overview of the various censorship threats facing Ethereum, and the corresponding solutions that are being worked on.
Censorship Threat #1
While PBS mitigates previous centralization issues, it also introduces new vectors of centralization at the builder level by enhancing builders' ability to review transactions. By creating a dedicated builder role, builders will have the ability to overbid for 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 blocks they built for the proposer are not full, and there are eligible transactions waiting in the mempool to be included.
crList allows the proposer to force the builder to fully utilize empty block space without allowing the proposer to explicitly dictate the order of transactions to be included: "Hey builder, please fill the empty block, or the transactions I choose will be rejected. included."
If the builder insists on reviewing transactions, and ignores the proposer's crList, the prover will reject the block (the prover is chosen at random, voting on the block header of the canonical chain after the block proposed by the validator). In short, crLists are an indirect mechanism that allows proposers to oversee a centralized market for block building without defeating the entire purpose of PBS (to decentralize proposers).
Solution 2
But what if the proposer could ask the builder to include the transaction, or what if they collude with the builder and tell the builder not to include the transaction? This leads to the second solution: MEV-smoothing. Just as crList constrains the builder, MEV-smoothing controls the proposer by removing its discretion.
The idea here is to ask provers to pay attention to the block building market, specifically with the fee bids attached to the blocks, and then only attest the block from the highest bid by the proposer. If the proposer is not proposing the most profitable block that has been built for them, something must be wrong, so the prover will ask: "Hey proposer, do you hate making money, or do you want to censor? In effect, MEV-smoothing aims to equalize the MEV profits of all proposers and create a perfectly efficient market that removes the incentive for proposers to engage in discriminatory censorship.
Solution 3
A third solution is to use encrypted memory pools. crLists are for builders and MEV-smoothing is for proposers, but encrypted mempools are designed to fight both. This mechanism is easy to understand: it encrypts the content of user transactions and send/receive addresses before they enter the mempool, and only decrypts them when they are on-chain. This makes it difficult for actors to censor or engage with MEV extraction technologies such as transaction front ends. This eliminates the need for a private memory pool like Flashbots Protect. Encrypted mempool technology is something that Cosmos developers, Flashbots, and privacy-oriented chains like Aztec are also experimenting with.
Solution 4
The fourth and final solution is the one we least want to rely on, but is also a good option: altruistic self-construction, in which case proposers simply choose to construct their own blocks rather than Outsource to builders. The advantage of this is that even with only a small number of altruistic builders around 10%, Ethereum can continue to grow.
The obvious downside here is that it works against economic incentives - recall that validators want to use MEV-Boost because it generates higher fees. This is why it is very important to promote a culture of censorship resistance and maintain decentralization at the social level.
Censorship Threat #2
image description
Source: clientdiversity.org
If a client is found to be buggy or under attack, there is a higher risk of network disruption. This is not theoretical speculation, as demonstrated by the Shanghai DOS attack incident in 2016, when attackers tricked the Geth client into slowing down its processing speed. In the merged Ethereum, two-thirds of the pledged ETH is required to achieve finality. A major client failure could temporarily stall the ethereum network (or worse: split) - making it critical that any given client run on no more than two-thirds of its validator nodes !
The problem of client centralization is so severe that even leading companies like Prysmatic Labs with the highest client usage are advising node validators to “use their competition.” After all, if Ethereum crashes, it's a loss for everyone.
solution
Note that the threat of censorship here applies not only to individual stakers, but also to centralized node providers like Infura and Alchemy, or decentralized node providers like Pocket Network. Solutions already implemented by Ethereum developers include various penalties to slash the share of inactive validators, such as the Inactivity Leak mechanism. On today's Beacon Chain, anti-dependency penalties are also harsher if misbehaving validators all fail on the same client. In effect, this promotes a multi-client culture (client diversity! ), while encouraging verifiers to consider not only technical risks but also economic incentives when choosing clients.
Censorship Threat #3
Source: Dune Analytics
Source: Dune Analytics
solution
There are no easy solutions, but there are reasons to be optimistic. First, although Lido controls 30% of the staked ETH, it does not exist as a single entity and has no direct influence on block building. Lido's ETH war chest is passed to 28 node operators who stake through tens of thousands of nodes to prevent any kind of unilateral network attack.
Decentralization maximalists won't find much comfort in 28 node operators, which is still too little considering staking (Ethereum network!). One possible technical solution to ETH's centralization problem is Distributed Validator Technology (DVT), also known as Secret Sharing Validator Technology, an area the Ethereum Foundation has been actively researching since 2019. The company spearheading the 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 distributes node running activities among different validators instead of a single validator. It uses a multi-party computation (MPC) process to ensure nodes can be run jointly by multiple validators, since private keys are "shared". Therefore, no actor 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.
first level title
04. Relayers
In the MEV-Boost model, relayers act as intermediate "brokers" between proposers and builders. Relays are a unique centralization vector, the result of Flashbots trying to solve the MEV problem. To understand the censorship threat here, it is first necessary to understand why repeaters appear.
Recall that the whole reason for wanting to split the validator role under PBS into proposers and builders is to curb the censorship power of validators and prevent one entity (such as Coinbase or Lido) from holding a large staked ETH share, You can decide arbitrarily what to include on-chain.
Therefore, in order for PBS to work, proposers need to be ignorant of the contents of the blocks they receive from builders. Otherwise, proposers will be able to distinguish which blocks they think should go on-chain, and we're back where we started before PBS.
This is what the repeater does under Flashbots' MEV-Boost model. A builder sends a bid for an assembled block to a relayer, who then sends the block to a hidden escrow and only reveals the price to any proposer who accepts the relayer's payload.
image description
Source: Devcon
censorship threat
But what if repeaters choose to censor themselves? This brings us to the heart of centralization risk at the relayer level. Today, 58% of relay blocks on Ethereum are reviewing Tornado Cash transactions, i.e. OFAC compliant. Most of this 58% (80%) came from Flashbots' relay blocks (see image below).
Note that there are many other validators still accepting blocks with Tornado Cash transactions, so this is actually a "soft" form of censorship manifested by a delay of a few minutes, rather than a "hard" form of censorship. As long as a small number of repeaters are not censored, the problem remains inconvenient for users, which is not what we traditionally think of as "censorship". Still, it’s an issue that has led to widespread scrutiny around ethereum in recent months.
solution
The obvious solution is to encourage wider repeaters. Validators are often connected to multiple relayers at the same time. As shown above, 3 out of 7 relayers (BloXroute and Manifold) do not censor Tornado Cash transactions. Because relayers are a permissionless entity, this makes it easy for anyone to create their own relayers (Flashbots themselves have open-sourced their own relayers). The low barrier to entry for creating non-censorship relayers means that this centralization vector is much lighter than at the validator level, where it is much more costly to block dishonest/misbehaving actors.
The good news is that repeaters are a temporary censorship vector in the long run. When PBS is formally incorporated into the protocol, relayers will no longer be needed, as builders will connect to proposers.
So, you should understand the whole MEV supply chain and what we're doing.
Note that this article only deals with soft censorship forms, which typically equate to block inclusion delays in seconds/minutes.
Original link
