Why is POS much more complex than POW when it comes to censorship?

Original Title: “OFAC Sanctions and Ethereum PoS: Some Technical Nuances”

Author: BitMEX Research

Translator: Block unicorn

Abstract: This article discusses the level of censorship resistance in Ethereum after the merge, against the backdrop of the U.S. Treasury Department's Office of Foreign Assets Control (OFAC) recently approving Tornado Cash on Ethereum. The report focuses on the technical characteristics and specifications of proof-of-stake systems, and how these characteristics and specifications will interact with sanctions if stakeholders choose to comply. We will also look at changes in the MEV auction system post-merge and how this will affect the level of censorship resistance on the network.

Our conclusion is that when it comes to censorship, PoS is much more complex than PoW. We also conclude that the MEV auction architecture upgraded for the merge makes the situation substantively worse, though this may be resolved in the future.

On August 8, 2022, the U.S. Treasury announced sanctions against Tornado Cash. We will not discuss the right or wrong of this here; instead, this report will focus on some technical considerations, particularly regarding how Ethereum will change after the merge and the switch to proof-of-stake (PoS).

It is important to note that in both proof-of-work (PoW) and PoS systems, the choices faced by miners and stakeholders in the face of these sanctions are not a simple binary choice; it is not a decision between banning OFAC transactions and ignoring OFAC bans. There are more nuances, and you could say there are three main choices:

1. Ignore OFAC rules
2. Refuse to include OFAC prohibited transactions in the blocks you produce
3. Refuse to build on chains that include OFAC prohibited transactions

Option 2 is considered a more conservative or moderate choice than option 3. Many believe that option 2 is also entirely legal; after all, block producers should be free to include any transactions they like. If they want to exclude certain transactions, that is also their free choice. On the other hand, option 3 is a more extreme choice, and many consider it an attack on the network. If those participating in option 3 only hold a small amount of hash power, it is likely to lead to censorship failure and cause significant capital losses for the censor. Conversely, if the censor holds a majority and succeeds, the network is in serious crisis and may have already failed.

### Complexity of Proof of Stake

When we consider Ethereum's proof-of-stake system, the situation becomes even more nuanced. In the face of these regulations, we identify at least 8 options, rather than just 3 significant choices. In fact, there are more options, but we will not detail them here.

1. Refuse to include "OFAC prohibited" transactions in the blocks you produce.
2. Refuse to validate blocks that contain OFAC prohibited transactions.
3. Produce and validate blocks that comply with OFAC rules, even if they conflict with non-compliant blocks.
4. Refuse to generate blocks on top of blocks that contain OFAC prohibited transactions.
5. Refuse to validate blocks in the chain that contain OFAC prohibited transactions.
6. Refuse to use blocks that contain OFAC prohibited transactions for block validation.
7. Refuse to include certifications for blocks in the chain because OFAC prohibits transactions in the blocks you produce.
8. Ignore OFAC rules.

Many in the Ethereum community see the prospect of this censorship as a major issue. In particular, a significant portion of the stake is concentrated in large financial institutions, which often operate under U.S. jurisdiction, such as Coinbase. Therefore, many advocate for special actions, such as an emergency UASF/HF (User Activated Soft Fork), to remove the interests of validators participating in this censorship. In fact, this is considered a major advantage of PoS. Exiting the validator pool may take a long time, and if a large number of stakes are involved, it could take at least several months.

Thus, the Ethereum community has time to arrange protocol changes to punish poorly behaving stakeholders. Under the PoW system, it is much more difficult to punish poorly behaving miners; conversely, if the community wants to change the protocol, all miners may need to be punished, not just the malicious ones.

Option 1: Refuse to include "OFAC prohibited" transactions in the blocks you produce

In any case, as we mentioned above, the type of censorship stakeholders engage in is very nuanced. Option 1 above is relatively mild. In our view, if a large staker chooses option 1, a UASF/HF is unlikely to occur. The only real impact is a small loss of revenue for the censor, which may lead to a loss of market share. Even if these censors hold 50% of the stake, it means that those trading with Tornado Cash only need to wait 24 seconds instead of 12 seconds to enter a block (assuming fees are high enough to enter the next block), which does not seem too damaging.

Meanwhile, block producers are free to include whatever they like in their blocks. Therefore, this action may be seen as legitimate, while the response of UASF/HF may be considered unjust and unethical. In our view, this approach (option 1) is the most likely to be realized in the medium to short term. This is certainly speculation, but Coinbase and the U.S. Treasury may reach a compromise and choose option one. However, explaining these nuances to regulators may be extremely difficult.

Option 2: Refuse to validate blocks that contain OFAC prohibited transactions

Option 2, refusing to validate blocks containing OFAC prohibited transactions, is much more complex and has many implications. First, some argue that this choice is theoretically incorrect. While technically, you could argue that when you validate a block, you are only choosing one block, the head block. If that block has OFAC prohibited transactions, you may have violated OFAC rules. On the other hand, this is not the true operation of the staking process. Stakeholders vote on a source block, a target block, and a head block; theoretically, stakeholders are actually validating all transactions between the last completed block and the head block. The fact that the head block is referenced in the certification is merely a technical detail.

In fact, for example, a chain split might have occurred three blocks ago, and then there could be two equally long competing chains, and then validators must choose which side to validate by selecting between the two head blocks in the same slot. In this case, why does OFAC only care about the transactions in the head block? Shouldn't they care about the transactions between the chain split and the head block, as that is what the voting actually decides? Of course, we are very skeptical that U.S. Treasury officials are currently working to resolve these confusing issues. However, it does illustrate that option 2 may have some theoretical flaws.

Despite this flaw, if option 2 is chosen, it may superficially appear to be as mild a choice as option 1. This action does not involve causing chain reorganization, and stakeholders should be free to choose which blocks they validate, which is their free choice. Therefore, this form of censorship can be seen as legitimate, while the response of UASF/HF can be viewed as unfair or extreme, just like option 1.

However, if we assume that most blocks contain OFAC prohibited transactions, the consequences of option 2 could be quite severe. Therefore, validators engaging in this censorship practice would participate very little in the network and earn zero rewards. In fact, they would have to pay penalties for inactivity. This would make staking almost meaningless; why just sit there being penalized when you could exit? Thus, in our view, UASF/HF may be neither unethical nor necessary to respond to the threat of a few validators choosing option 2.

It should also be noted that even before the merge, you could exit the staking pool, allowing you to avoid inactivity penalties. However, you could not withdraw those funds to the execution layer. About 12 months after the merge, there will be what is called a second merge, which may allow for full withdrawals.

If the censoring validator pool is large enough, the entire network may be unable to confirm blocks, essentially causing the network to stop working. Therefore, over time, the penalties for large inactive pools will grow larger. Thus, as before, choosing option 2 is almost meaningless; instead, validators may exit the system. On the other hand, if these resource pools are large and also involve censorship of option 1, the situation may become more ambiguous. Now, there may occasionally be some OFAC-compliant obstacles, and when the opportunity arises, the censor pool may be able to validate some obstacles if the censor is in the right committee.

It is difficult to determine what the outcome will be. The earnings of the censoring validator pool will be negatively impacted, but during certain periods they may still make money, which may depend on the ratio of the censor pool to the non-censor pool. Even if the censor pool holds a vast majority, it is unclear whether users of Tornado Cash really lost; they may need to wait a bit longer for confirmation, but the final confirmation time should be as quick as others.

Thus, the censorship itself may still largely be ineffective. There is also the possibility that the network processes blocks more slowly, which could be a problem. Therefore, if this occurs, Ethereum developers and the community may choose UASF/HF. However, in our view, protocol changes still seem unlikely, and we do not believe UASF/HF is justified.

You can also do some basic math here; if 50% of validators participate in the censorship of options 1 and 2, the situation could be as follows:

1. 50% of validators (well-performing validators) validate 100% of the time.
2. 50% of censors (the censoring validators) validate only 50% of the time, only validating on OFAC-compliant blocks.
3. Therefore, the average network validation participation rate is 75%.

If 100% of validators engage in censorship, all blocks are OFAC compliant, and all blocks can be validated. If 0% of validators engage in censorship, all blocks can be validated. In a 50:50 situation, perhaps the "worst case," it leads to a potential 75% validation rate. Thus, 75% is the lowest average validation participation rate that can be achieved in this case. Since 75% is above 66.7%, it seems that this chain should have some viability and continue to move forward.

Of course, there are many assumptions in these calculations, as it is impossible to achieve this perfectly in practice. It seems that in these cases, regardless of how the percentages are divided, as long as a significant portion of validators are honest, the censorship system will not be particularly effective.

Theoretical Average Network Validation Participation Rate

Note: Assuming there is always a transaction that is prohibited by the censor, which can be included in the shield. Assume the censor: 1) never includes prohibited transactions in their blocks, 2) never validates a block with a prohibited transaction.

The above figure illustrates that a balance point may emerge in the middle, allowing the network to continue forward with some censorship in place. If the proportion of censors is too low, for example below 25%, the inactivity penalties may be too high, forcing the censors to leave. Then the remaining validators would be 100% honest. Outside of this scenario, one could argue that the network could sustain itself for a while under this limited censorship regime. Theoretically, no one may need to fix anything. However, the censors will still earn lower rewards and may want to leave at some point.

The above situation indicates that option 2 has the potential to be quite chaotic and confusing. Its logical variant, option 5, which refuses to validate blocks that contain OFAC prohibited transactions in the chain, perhaps starting from the last financing block, may be simpler. In option 5, the censor pool will never validate blocks; they will simply incur large penalties, leaving no reasonable choice but to exit. Therefore, UASF/HF is unlikely to be necessary.

Option 3: Produce and validate blocks that comply with OFAC rules, even if they conflict with non-compliant blocks

This choice is more extreme and is likely seen by many in the Ethereum community as an attack. This could lead to chain reorganization. However, significant reductions may still be avoidable. This action could lead to UASF/HF protocol changes and result in losses for the attacking pool. It could also lead to a persistent chain split, especially if stablecoin custodians choose the OFAC-compliant chain, which we will not detail here.

Conclusion

We will not cover all censorship options in this report. What we want to illustrate is that the censorship scenario is more complex than in proof of work. For Ethereum, this complexity can be both positive and negative. A potential positive factor is that regulators may not know what action to take, which could lead to a reduction in regulatory actions. A potential negative impact is that option 2 could lead to many issues, even though it is just a relatively mild choice that does not lead to reorganization, making it difficult to define as an attack. It should also be noted that these forms of censorship may require new clients and a significant amount of technical work. To our knowledge, this work has not yet been completed.

As for the overall impact of this potential censorship and regulatory action, the most likely mid-term outcomes may be as follows:

• Slower network completion times.
• No actual effective censorship targeting end users, just slightly delayed experiences.
• Reduced staking by large financial institutions, leading to lower overall staking levels in Bitcoin, resulting in higher yields.

MEV Auction Process / Flashbots (Open Source MEV Bots)

We previously explained the MEV auction / Flashbots in our May 2022 report. At that time, there was no clear plan for the post-merge MEV auction process. Significant progress has been made in the past few months, and the infrastructure has been built. First, it is important to note that after the Ethereum merge, there is a distinction between execution layer clients (like Geth) and consensus layer clients (like Prysm). Currently, the execution layer client does everything, handling all transactions and smart contracts, and deciding which chain to follow. After the merge, users will need to run two clients to track and validate the chain: an execution client to handle transactions and a consensus client to produce blocks and determine the largest benefit chain.

Therefore, before the merge, it was the execution client (Geth) that was adapted to add Flashbot functionality. After the merge, since blocks are produced by the consensus layer, it is the consensus layer client that will need to add Flashbot-type functionality.

To our knowledge, all five competing consensus layer clients have implemented a Flashbots-type system as a standard feature, using a system called MEV-Boost. This is slightly different from the situation before the merge. To run Flashbots before the merge, miners had to download a special version of Geth called MEV-Geth. Now, MEV-Boost seems to have been incorporated into the standard.

Remember, the MEV auction system has a trusted central relay server, so some might argue that making MEV-Boost standard could increase centralization. However, the URL of the Flashbots relay server does not seem to be standardized as we see in the consensus layer clients; rather, it requires manual configuration. The URL of the Flashbots server is included in the user guide and setup instruction pages, which we have seen in the consensus layer clients. Therefore, determining the extent of the growth of centralization remains an open question.

It should also be noted that, to our knowledge, Flashbots indicates that the relay server is already OFAC compliant and censoring transactions. On August 17, 2022, to help alleviate this issue, Flashbots announced that it was accelerating the process of making the relay server code open source. This should mean that more people can run relay servers, and then miners/stakeholders can manually choose which relay to select. Therefore, if one relay server censors, users can switch to another.

However, as we mentioned in our May 2022 report, there are many centralizing forces surrounding relay servers: 1) Running them is very complex and requires a lot of resources and expertise; 2) Server operators must be trusted to ensure they do not run ahead of seekers or engage in other dishonest behavior. Therefore, reaching a destination with a diverse, vibrant, and plentiful selection of relay servers may be challenging. In particular, this situation is unlikely to occur before the merge.

New MEV-Boost Architecture "All or Nothing"

We believe that certain aspects of the new MEV auction infrastructure are much worse from the perspective of centralization and resistance to censorship, even more important than the relay server issue. In our May 2022 Flashbots report, we stated:

Miners participating in the Flashbots system are also free to include any non-Flashbot transactions in their blocks, which they can obtain by connecting to the public transaction memory pool. Miners subscribing to Flashbot transactions need to run a special modified version of Geth called MEV-Geth. In our view, the key is that mining nodes also need to connect to the "regular" memory pool and consider adding these transactions. This sharply contrasts with the view that claims Ethereum has a single point of failure due to the widespread adoption of miners using Flashbots.

To our knowledge, the new infrastructure no longer seems to be the case. It is no longer possible to add transactions from the memory pool to the transactions and transaction packages in the MEV auction system using traditional methods. It now appears that it is all or nothing. Block producers must build the entire block using the MEV auction system. In our view, this is a major weakness that increases the risk of centralization. We are not sure why this situation has arisen, but it does not seem to be an inherent weakness of PoS.

It may simply be that the development time for MEV-Boost was tight, and this feature has not yet been implemented. Therefore, at some point in the future, this functionality may be added, and this major issue may be resolved. However, to our knowledge, this is unlikely to happen before the merge.