Ethereum has not yet achieved censorship resistance… Here’s what developers are doing.
Everyone knows regulators hate cryptocurrencies, but this sanction caught DeFi off guard. This represents an unprecedented effort by U.S. regulators to officially crack down on cryptocurrencies.
In a way, the sanctions against Tornado Cash are a blessing in disguise. This regulatory shock reminded DeFi of its fundamental principles, which scrutinized every centralized bayonet across the decentralized finance landscape.
Decentralization is actually important.
Any centralized shortcut you take can be used against you.
The topic of censorship is difficult to understand. Trying to understand the concerns surrounding Ethereum’s centralization requires some technical knowledge, and the sea of crypto terminology is difficult to wade.
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 disgustinator) can easily understand.
I listed each of the major centralization vectors on the Ethereum protocol and briefly described the various market and technology solutions that entrepreneurs and developers are working on.
A brief overview of the Ethereum supply chain
Ethereum’s original design theory involved only two participants: users running their own nodes, sending transactions through a peer-to-peer network to block validators, who would build a block and contain that transaction.
Blockchain validators (we call them miners in PoW and stakers in PoS) are supposed to be neutral participants in validating blocks.
In fact, the process is much more complicated. By selling blocks to searchers running arbitrage bots, validators face perverse incentive discrimination. 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 has 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 their wallets through the front end of the dapp. These transactions are sent to the mempool;
- Searchers run arbitrage robots and scan the mempool, then bundle trades together;
- The bundled transaction is passed to the block builders, who in turn attach a fee bid;
- If both the builder and validator are connected to a repeater, then the relayer will hide the bundled block until it is submitted for auction;
- The validator (i.e. the block proposer, proposer) selects the fee bid and proposes the block;
- Attestors validate the block before it is finally on the chain.
(Note that in this article, the terms validator and proposer are used interchangeably.) ）
In this transaction sequence, there is a centralized vector at each step.
Let’s start with the front end and look at it in turn.
1. Front-end interface
If you want to buy some ETH, you can go to uniswap.com, whose beautifully designed, sleek pink and white user interface helps you trade easily. You connect to MetaMask, select your liquidity pool, and click “Send” to execute the trade. We take this simple process for granted, but there are already many centralized threats emerging from these intermediaries.
Today, many dapps have centralized front-end interfaces. Web3’s short history shows that when regulators come knocking, DeFi answers. This happened when Balancer hid a $20 million liquidity pool on its frontend, or when Uniswap Labs quickly removed dozens of synthetic derivative tokens from its frontend to circumvent SEC scrutiny. MetaMask and Infura have done the same to block wallet addresses that comply with Tornado Cash sanctions.
Crossing 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.
Ideally, everyone can run their own node. But as Signal founder Moxie Marlinspike once pointed out in her criticism of Web3, most people don’t run their own nodes, which creates a reliance on centralized node service providers like Infura and Alchemy. They make life a lot easier with DeFi, but as you know, it comes at a cost. Since a large number of dapps such as Uniswap and Metamask in turn rely on Infura to run nodes, an important centralization vector has emerged on this end.
Centralized companies 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 US political sanctions. There are also some technical reasons for the problems with centralized node providers. Ethereum experienced a network outage in November 2020, when Infura’s mainnet API was paralyzed by its Geth client not being updated and many dapps were unusable.
Finally, the node needs to be hosted somewhere. In fact, many Ethereum nodes are hosted on centralized cloud service providers such as AWS, Hetzner, and Google Cloud (as are Solana and Bitcoin). The centralization vector here is obvious: the cloud provider can stop the server at will. The community received this alert in August of this year when Hetzner clarified that running Ethereum nodes on its servers violated its terms of service.
There are already so many centralized vectors that we haven’t even talked about the mempool.
What to do?
Front-end centralization is a relatively minor issue. This is thanks to the thriving DeFi middleware ecosystem, which allows us to bypass censored dapps frontends in various ways through alternative venues. Examples include portfolio trackers like Zapper and Zerion, crypto wallets that integrate “exchange” functionality, and DeFi aggregators like 1inch and Paraswap. They allow you to access dapps without direct access. Most dapps like Uniswap are also dedicated to open-sourcing the code for their frontends, allowing any individual or even a dedicated DAO to recreate the frontend.
To bypass censored frontends, decentralized storage providers like IPFS are also used to host front-end domains with static content. For front-ends 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 domains, decentralized domain name services like ENS provide a more censorship-resistant way to host domain names by building domain names on Ethereum smart contracts. This is different from most websites stored on centralized DNS servers today and are vulnerable to domain seizure or IP address blocking.
Together, these decentralized infrastructure protocols form the basic building blocks of a decentralized Web3 economy on the DeFi frontend.
For the node centralization problem, the key technical solution is light client. 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, and we can broadcast transactions and make requests to any full node that accepts queries from lightweight clients. By doing so, dapps can facilitate transactions instead of calling centralized RPC endpoints like Infura or Alchemy.
Light clients do not attempt to retrieve the entire beacon chain or set of validators. This will require a lot of calculations – hence the name “light”! They simply synchronize the block headers by knowing the peers. The point is that this process is performed in a trustless manner through randomly assigned groups of validators (sync committees). The Beacon Chain PoS light client is also much simpler to build than the PoW light client. The node centralization problem is mitigated by having only a few non-censored full nodes that answer these queries. For more information on light clients, see here:
(1/25) @ethereum Fundamentals: Sync Committees and Light Clients
Just about one year ago, the Altair upgrade gave validators a new duty: sync committee. Learn how this core consensus feature enables the end game:
A truly decentralized World Computer pic.twitter.com/xzzm9GF2nR
— Haym (@SalomonCrypto) October 10, 2022
When we want to rely on external node providers, there are decentralized Infura alternatives, such as Pocket Network or Ankr, that minimize the need for Infura.
To recall, the problem here is that people lack incentives to run their own nodes. These RPC node providers introduce economic incentives. Taking Pocket Network as an example, node providers stake POKT to run blockchain nodes and relay data between different blockchains to provide services for dapps that request on-chain data. In this permissionless market, the more relays they serve, the more POKT rewards they receive. On the demand side, the user/dapp also stakes POKT, allowing it to request relays on the network. Note that these projects themselves have centralized points, but there is a roadmap to remove them.
Source: Sami Kassab
The node hosting issue is a centralized risk that needs to be constantly monitored, but it is not a big threat due to the low exit barriers. If AWS decides to restrict node hosting on its cloud servers, node operators can easily move to another cloud server without being locked anywhere. Thanks to the merger, it is now easier to set up your own nodes with DIY hardware (Raspberry Pi) and plug-and-play solutions (Avado).
After the user transaction is successfully submitted, it enters the mempool. A mempool is a database of pending transactions submitted by ordinary users like you and me, sometimes referred to as the “dark forest” of Ethereum. The MEV (Maximum Extractable Value) game starts here.
Once the deal hits the mempool, searchers begin scanning the Dark Forest for lucrative MEV opportunities. Searchers are usually large institutions and proprietary trading platforms that run arbitrage robots, but sometimes individuals are also included. They pay high gas fees to get validators to accept their trading orders instead of going through public pools.
One thing to note here is that although people often think that MEVs are completely bad, there are also good MEVs. In the case of highly volatile cryptocurrency prices, the DeFi protocol requires a quick liquidation of the lender’s collateral, and it needs to pay high gas fees to ensure that transactions can be executed quickly. If the blockchain is designed on a first-come, first-served basis, then DeFi will be very inefficient. Searchers play an important role in balancing this efficiency and building efficient blocks.
However, when it comes to bad MEVs, while searchers are not centralized risks per se, they play a role in enabling huge centralization vectors by colluding with block builders. Their role at the protocol layer is to bundle transactions and pass them to the next echelon of block builders in the Dark Forest.
3. Block builders and validators/proposers
1) Proposer Builder Separation (PBS) before
Before the Ethereum merger, block building was performed by one entity: miners. This allows miners to take advantage of DEX arbitrage and liquidation by distinguishing transactions in the mempool.
Over time, the problem gets worse. Searchers and miners began colluding in the underground market to most efficiently select transactions in order to maximize their own MEV profits. This ultimately drove up the fixed costs of being a miner, as large pool operators had the capital to run complex algorithms that outpaced family-run miners – giving rise to what we know as MEV. The total amount of MEV withdrawn on Ethereum in the past two years has reached $675 million!
There are two problems with the centralization risk here: first, it hurts Ethereum users, who end up waiting longer or paying more transaction fees; Second, well-capitalized block validators are in a better position to review due to political pressure.
To counter this, Ethereum developers are working on an in-protocol solution known as Proposer-Builder Separation (PBS). As the name suggests, PBS separates the validator role into two separate native roles:
- Proposer (i.e. validator who stakes 32 ETH and builds blocks).
- Block builder
Under PBS, block builders compete with each other to create an aggregated ordered list of transactions from searchers. These transactions are bundled together for optimization to maximize the builder’s own MEV fees, which are then passed on to the block proposer. Proposers are incentivized to select transactions based on the highest fees to create blocks and send them to the network, which is packaged on-chain.
This reduces the centralized power of block proposer review, as the person building the block is not the same person who selects the transactions to include in the block. As Vitalik describes in The End of Blockchain Scaling, PBS is all about maximizing the decentralization of validators.
But PBS is technically complex and will not be ready for several years (maybe 2-8 years later!). The good news is that temporary solutions to address validator centralization have emerged in the meantime.
First, the merged validator is randomly selected as a block proposer in each slot (slot). This is different from the pre-merger PoW, where all miners validate new transactions by solving mathematical puzzles. After one of the approximately 420,000 validators on Ethereum is randomly selected as the block proposer, the other validator committee is randomly selected to submit a proof of validity (vote) on the proposed block. What this two-layer random shuffle layer does is 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 (proposer is separated from builder!). )
Why use Flashbots? The reason validators do this is simple, because staking rewards are more profitable for them. Flashbots’ software distributes MEV value more equitably between proposers and builders, rather than between large mining pools and searchers. What Flashbots do is stop insider collusion between searchers and miners by creating a transparent, open price discovery market. According to Hasu, using MEV-Boost increased the merged staking reward for validators by 135%.
Note that MEV-Boost is optional, and validators still have the option to build their own chunks on their execution client.
Proposer/Builder Separation (PBS) era
PBS eliminates centralized power for large validators. But even after PBS was designed, we haven’t reached the promised land of decentralization. In the post-PBS era, the centralized vector, while mitigated, will still exist. The rest of this section will provide a brief overview of the various censorship threats facing Ethereum and the corresponding solutions it is working on.
While PBS alleviates previous centralization issues, it also introduces new centralization vectors at the builder level by enhancing the builder’s ability to review transactions. By creating a dedicated builder role, builders will have the ability to overbid on blocks and exclude certain transactions.
The first solution is censorship-resistant lists (crlists), also known as “hybrid PBS.” Suppose we suspect that the builder is trying to review the transaction. We know this because the blocks they build for the proposer are not full, and there are eligible transactions in the mempool waiting to be included.
crList allows the proposer to force the builder to make the most of the empty block space, without allowing the proposer to specify the order of transactions to be included: “Hi builder, please fill the empty block, otherwise the transaction I chose will be included.” ”
If the builder insists on censoring the transaction and ignores the proposer’s crList, the prover will reject the block (the prover is randomly selected and votes on the block header of the canonical chain after the proposer proposes the block). In short, crLists is an indirect mechanism that allows proposers to oversee a centralized block-building market without defeating the entire purpose of PBS: decentralizing the proposer.
But what if the proposer can ask the builder to include the transaction, or 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 keeps builders restrained, MEV-smoothing controls proposers by removing their discretion.
The idea here is to ask the prover to pay attention to the block building market, specifically with the fee bid attached to the block, and then only prove the block with the highest bid from the proposer. If the proposer is not proposing the most profitable money 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 review?” “In effect, MEV-smoothing aims to make all proposers MEV equally profitable and create a fully efficient market that removes the incentive for proponents to engage in discriminatory review.
The third solution is to use an encrypted memory pool. crLists is used against builders, while MEV-smoothing is used against proposers, but encrypted mempools are designed to work against both. This mechanism is easy to understand: it encrypts the contents of user transactions and send/receive addresses before they enter the mempool, and only decrypts them on-chain. This makes it difficult for actors to review or engage with MEV extraction techniques, such as the transaction front-end. This eliminates the need for a private memory pool like Flashbots Protect. Cryptographic mempool technology is something that Cosmos developers, Flashbots, and privacy-oriented chains such as Aztec are also experimenting with.
The fourth and final solution is the last thing we want to rely on, but it’s also a good option: altruistic self-building, in which the proposer simply chooses to build their own block rather than outsource it to the builder. The benefit of this is that Ethereum can continue to grow even with only a handful of altruistic builders around 10%.
The obvious downside here is that it runs counter to financial incentives – recall that validators wanted to use MEV-Boost because of the higher fees it could incur. That’s why it’s important to promote a censorship-resistant culture and maintain decentralization at the societal level.
Today, to participate as an Ethereum validator, you need to stake 32 ETH in a deposit contract, running two software clients simultaneously: the execution client (executing transactions) and the consensus client (reaching consensus on newly generated blocks). The threat today is that too many validators are running the same execution client, Geth.
If a client is found to have a bug or is under attack, it poses a higher risk of network outages. This is not a theoretical guess, as evidenced by the 2016 Shanghai DOS attack, when attackers tricked the Geth client into slowing it down. In the merged Ethereum, two-thirds of the staking ETH is required to reach finality. A failure of one major client could temporarily bring the Ethereum network to a standstill (or worse: split) – making it crucial that any particular client runs on no more than two-thirds of validator nodes!
The problem of client centralization is so severe that even leading companies with the highest client usage like Prysmatic Labs advise node validators to “use their competitors.” After all, if Ethereum crashes, it’s a loss for everyone.
Note that censorship threats here apply not only to individual stakers, but also to centralized node providers like Infura and Alchemy, or decentralized node providers like Pocket Network. Solutions that Ethereum developers have implemented include various penalties to cut the share of inactive validators, such as the Inactivity Leak mechanism. On today’s beacon chain, if misbehaving validators all fail on the same client, the anti-correlation penalty is even harsher. In fact, this promotes a multi-client culture (client diversity!). ), while encouraging validators to consider not only technical risks but also financial incentives when selecting clients.
Finally, another censorship threat that is often mentioned at the validator layer is centralization in ETH staking services. Liquid staking protocols (such as Lido and Rocket Pool) and CEX (centralized exchanges such as Coinbase and Kraken) control about 37% and 31% of staked ETH, respectively. This is a serious problem because any entity with more than 33% ETH is likely to double-spend.
Source: Dune Analytics
There are no easy solutions, but there are reasons to be optimistic. First, although Lido controls 30% of staked ETH, it does not exist as a single entity and has no direct impact on block building. Lido’s ETH War Fund was passed to 28 node operators, who stook tens of thousands of nodes to prevent any form of unilateral cyberattack.
Decentralized maximizers won’t find much solace in 28 node operators, which is still too little considering staking (Ethereum network!). One technological solution that could potentially solve the ETH centralization problem is Distributed Validator Technology (DVT), also known as secretly shared validator technology, an area that the Ethereum Foundation has been actively working on 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 activity among different validators rather than individual validators. It uses a multi-party computation (MPC) process to ensure that nodes can be run by multiple validators because the private key is “shared.” As a result, no actor has full access to the private key needed to sign the information. This also allows a validator to replace another validator in the event of an infrastructure failure.
Finally, while liquid staking protocols that hold too much ETH are very worrying, it’s worth considering assuming that a Lido DAO doesn’t exist. In that case, ETH would be staked by politically more vulnerable entities like Coinbase and Kraken, which already hold large amounts of ETH, which would be much worse than the status quo.
In the MEV-Boost model, repeaters act as an intermediate “broker” between proposer and builder. Repeaters are a unique centralized vector that is the result of Flashbots’ attempts to solve the MEV problem. To understand the censorship threat here, one first needs to understand why repeaters appear.
Recall that the whole reason for wanting to split the validator role into proposer and builder under PBS was to curb validators’ censorship power and prevent one entity (such as Coinbase or Lido) from holding a large number of staked ETH shares, arbitrarily deciding what to include on-chain.
Therefore, in order for PBS to work, proposers need to know nothing about the block content they receive from the builder. Otherwise, the proposer will be able to distinguish the blocks they think should be on-chain, and we’ll go back to where we started before PBS.
This is the role of repeaters under the MEV-Boost model of Flashbots. The builder sends a bid for an assembled block to the repeater, which then sends the block to a hidden hosting and only reveals the price to anyone who accepts that repeater payload.
The block contents are displayed only after the proposer undertakes to sign the block header and accept the bid. This way, proposers who want to review Tornado Cash transactions have no choice but to continue proposing blocks on-chain because they have already paid for it.
But what if the repeater himself chooses to censor? This brings us to the heart of centralized risk at the repeater level. Today, 58% of relay blocks on Ethereum are censored for Tornado Cash transactions, i.e. OFAC compliant. Most of this 58% (80%) comes from the relay blocks of Flashbots (see figure below).
Note that there are many other validators who are still accepting blocks with Tornado Cash transactions, so this is actually a “soft” form of censorship that manifests itself as a delay of a few minutes, rather than a “hard” censorship form. As long as a few of the repeaters do not undergo censorship, this issue remains inconvenient for users, which is not what we traditionally think of as “censorship”. Still, it’s an issue that has led to widespread concern surrounding Ethereum being censored in recent months.
The obvious solution is to encourage a wider range of repeaters. Validators are usually connected to multiple repeaters at the same time. As shown above, 3 of the 7 repeaters (BloXroute and Manifold) do not censor Tornado Cash transactions. Because Repeater is a permissionless entity, this makes it easy for anyone to create their own repeater (Flashbots itself has open-sourced its own repeater). The low barrier to entry for creating a non-censored repeater means that this centralized vector is much lighter than at the validator level, and it costs much more to block dishonest/misbehaving participants at the validator level.
The good news is that repeaters are a temporary censorship vector in the long run. When PBS is officially included in the protocol, repeaters will no longer be needed because the builder will connect to the proposer.
So, you should understand the entire MEV supply chain and what we’re doing.
Note that this article only deals with the soft censorship form, which usually equates to a block inclusion delay in seconds/minutes.
This article is not exhaustive — I’ve omitted more middleware protocols like oracles, sidechains, and rollups, which have their own centralization vectors. Forms of hard censorship like the 51% attack, as well as technical and social solutions against them, are also not included in this article.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/ethereum-the-road-to-censorship/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.