Ethereum PoS in the context of OFAC sanctions - some technical details

BitMEX Research Authors Discuss Ethereum's Censorship Resistance After Activating The Merge in the Context of a Recent DecisionOFAC (U.S. Office of Foreign Assets Control) to impose sanctions on the Tornado Cash mixer smart contract.

The focus is on technicalthe features of the proof-of-stake system and how it can censor transactions and respond to this censorship if the stakers comply with the sanctions, in whole or in part. We'll also talk about the changes to the MEV auction system after The Merge and how this might affect the network's censorship resistance. The conclusion is that proof-of-stake is much more difficult in terms of network censorship resistance than proof-of-work. It is also important that the updated MEV auction architecture for The Merge significantly exacerbates this problem, although this factor may be mitigated in future software updates.

Overview

On August 8, 2022, the U.S. Department of the Treasury announced the designation of the Tornado Cash smart contract mixer, which runs on Ethereum.We will not go into much detail here about the legality or illegality of this decision, although it ishighlya rich topic for discussion (sanctions against open source software and harassment of its developer).But we're going to focus more on some technical considerations as to how exactly it canchange Ethereum after activating The Merge and switching to proof-of-stake (PoS).

It is probably necessary to start with the fact that inproof-of-work (PoW), and in PoS systems, the choice facing miners and stakers facing such sanctions is not simple and binary. It is not just a choice between deciding to block transactions at the request of OFAC or to ignore such requests. There are more nuances here. We can say that there are three basic options:

1. ignore OFAC rules;
2. refusal to include transactions prohibited by OFAC in their blocks;
3. refusal to continue a blockchain branch that includes transactions prohibited by OFAC.

The second option can be called much moreconservative and moderate in comparison with the third. Many also believe that option 2 is perfectly legitimate: after all, block creators should have the right to include any transactions they want in them. And if they want to exclude certain transactions, then this is their free choice.

Option 3, on the other hand, seemsmuch more extreme and is regarded by many as an attack on the network. If those who follow the third option control a smaller portion of the hashrate, this is likely to be a failed censorship attempt and result in a significant loss of capital for would-be censors. If such a censor (collective or not) is in the majority and succeeds, this means a serious crisis for the network, perhaps even an existential one.

Difficulties associated with proof-of-stake

Turning to the features of the proof-of-stake systemEthereum, even more nuances appear. Instead of three basic options for responding to such regulatory requirements, we found at least eight possible options. In fact, more could be singled out, but we will not delve into such jungle here.

1. Refusal to include transactions prohibited by OFAC in their blocks.
2. Refusal to confirm blocks containing transactions prohibited by OFAC.
3. Create and validate blocks that match OFAC rules, even if they conflict with blocks that don't.
4. Refusal to create blocks on top of those that contain transactions prohibited by OFAC.
5. Refusal to confirm blocks in a blockchain containing transactions prohibited by OFAC.
6. Refusal to include in your confirmation blocks blocks with transactions prohibited by OFAC.
7. Refusal to include in their confirmation blocks blocks in the blockchain containing transactions prohibited by OFAC.
8. Ignore OFAC rules.

Many members of the Ethereum community (andthe crypto community as a whole) see such censorship as a serious problem. In particular, a significant portion of the “staking” (capital blocked for staking) of Ethereum is concentrated in large financial institutions, often in US jurisdiction, such as Coinbase. Therefore, many are in favor of potentially taking emergency measures - such as a UASF (user-activated soft fork) or a hard fork - to remove the collateral of validators that implement such censorship. This is even touted as an important benefit of PoS.

Leaving the validator pool can take a long timetime - at least a few months, if we are talking about a major participation. This gives the Ethereum community time to organize a protocol change and punish the guilty stakers. With PoW, it is much more difficult to target only unscrupulous miners, and if the community goes for such a protocol change, then most likely all miners will have to be punished, not just malicious ones.

Option 1: Refusing to include OFAC prohibited transactions in your blocks

In any case, as we have already indicated, specificoptions for implementing censorship by stakers have many nuances. Option 1 looks pretty bland. In our opinion, the choice of such an option by a large staker can hardly lead to a user soft fork or a hard fork of the network. The only real consequence in this case would be a small loss of profit for the censor, which could lead to a reduction in market share. Even if such censors controlled 50% of the total stake, this could mean that those who interact with Tornado Cash would have to wait 24 seconds instead of 12 for their transaction to be included in the block (assuming a sufficiently high fee). It doesn't look like a major inconvenience.

At the same time, block creators are free to include inthem anything that is considered correct, as long as it does not violate the rules of the network. This means that such behavior of the stakers can be considered as legitimate, and the response UASF or hard fork as unjustified and unethical. From our point of view, it is this approach (option 1) that looks most likely in the short and medium term. And this, of course, is nothing more than a guess, but it seems that Coinbase and the US Treasury could come to a compromise on this matter and stop at this option. Although explaining all these nuances to regulators can be very difficult.

Option 2: Refusal to confirm blocks containing transactions prohibited by OFAC

This is a much more complex scenario that canhave many consequences. First, there is an argument that this option is theoretically incorrect. Although technically it can be said that by confirming a block, you select only one block, the top one. If there are transactions in this block that are prohibited by OFAC, this can probably be interpreted as a violation of OFAC rules.

On the other hand, the staking process is actuallydoesn't work like that. The staker votes on the source block, the target block, and the top block, and in theory, the staker actually confirms all transactions in the range from the last finalized block to the top block. The fact that the confirmation mentions the top block is just a formality.

Imagine what happened three blocks agochain separation. It is then possible for two competing chains of equal length to exist, and the validator needs to choose one of them by choosing between the top two blocks in the same slot. In this scenario, why should OFAC only care about transactions in the top block? Shouldn't they also be interested in transactions from the chain split up to the top block? After all, this is the choice that the staker actually makes. We doubt that US Treasury officials are now ready to deal with these confusing nuances. However, this shows that option 2 is flawed in theory.

Otherwise, the staker's decision to follow the variant2, at first glance, may seem like a soft choice, as does var. 1. This action is not related to the reorganization of the blockchain, in addition, the stakers are free to choose which blocks they confirm - this is their free choice. Therefore, this form of censorship can be seen as legitimate, and a UASF or hard fork retaliation as an unfair or over-reaction, as is the case with Option 1.

However, assuming that most of the blockscontain transactions prohibited by OFAC, the consequences of the second option can be quite serious. Validators practicing this approach to censorship will rarely participate in the network and receive zero income. In fact, they would also have to pay fines for inaction. This would make staking completely pointless. Why just sit and get fined when you can just walk away?

Therefore, in our opinion, UASF or hard forkwould not be an ethical or necessary response to the threat of choosing option 2 by a small number of validators. It is also worth noting that even before The Merge is activated, you can leave the staking pool and thereby avoid penalties for inaction. You just can't bring your pledge back to the execution level. Such a withdrawal may become available approximately 12 months after the activation of the first The Merge, after the so-called second merge.

If the pools of censoring validators arelarge enough, the entire network may not be able to finalize blocks and, in fact, will cease to function. Large inactive pools may receive larger and larger penalties that increase over time. So, again, choosing option 2 is almost pointless, as validators can simply log out instead.

On the other hand, if these pools are large andalso participate in censorship under option 1, then the situation may develop somewhat more vaguely and incomprehensibly. In this case, OFAC blocks will appear from time to time, and censor pools may validate some blocks when they can, if the censor is on the correct committee. It is difficult to determine what the result will be in this case. This will negatively affect the income of pools of censoring validators, however, in some periods they will still be able to earn. And the result here will depend on the percentage ratio between censoring and non-censoring pools.

Even if the censoring pools arelarge majority, it is not clear whether Tornado Cash users really lose significantly: they may just have to wait a little longer for the first confirmation, but the finalization after that should occur in the same time frame as for the rest. Therefore, censorship itself can still be largely ineffective. It is also possible that the network will be slower to finalize blocks, and this can be a problem. Therefore, it is likely that in this case, the developers and the Ethereum community will decide to conduct a UASF or hard fork. But in our opinion, a protocol change is still unlikely here, and we are not sure that a UASF or hard fork will be justified.

You can try to calculate some basic probabilities. If 50% of the total stake is censoring options 1 and 2, then the situation may be as follows:

1. 50% of (“good”) stakers participate in 100% block confirmations.
2. 50% of censoring stakers are involved in validating 50% of blocks that only comply with OFAC rules.
3. The average level of participation in the system is 75%.

If 100% of validators censor transactions, thenall blocks comply with OFAC rules and all valid blocks can be confirmed. If 0% of validators censor transactions, then all valid blocks can be confirmed. The 50:50 allocation scenario is probably the worst outcome, with a potential participation rate of 75%. That is, 75% is the lowest average approval participation rate that can be achieved in this scenario. Since 75% is more than 66.7%, the blockchain needs to remain generally viable and keep moving forward. Although, of course, there are many assumptions in these calculations, in practice nothing works perfectly. It seems that in these scenarios, regardless of the percentage distribution, as long as a significant proportion of the validators are honest, censorship will not be particularly effective.

Theoretical average participation rate in block confirmations
Notes:it is assumed that there is always a transaction available for inclusion in the block that the censor would reject. Censors are expected to: 1) never include banned transactions in their blocks, and 2) never validate blocks with banned transactions.

The graph above shows that there is a possibilityequilibrium points, in the middle, where the network continues to operate under some censorship. If the proportion of censoring validators is too low—for example, less than 25%—the penalty for inactivity will be too high, and the censors will be forced to leave the network. Then 100% of the remaining validators will be honest. Apart from this scenario, one would expect the network to exist for some time with such limited censorship. Theoretically, there might not be a need for someone to fix something. However, censors will still earn less and may leave the network at some point.

There is also an argument in favor of the victory of censorship.If there are censoring stakers on the network—even a minority—then block creators may be concerned that their blocks will be less likely to end up on the winning chain if they contain transactions prohibited by OFAC. Therefore, in a “least tolerant wins” logic, to protect themselves and their jobs, many block creators may voluntarily comply with OFAC sanctions and restrictions. Then these sanctions can be effective to some extent.

All of the above shows that option 2looks rather confusing and can potentially lead to a wide range of poorly predictable consequences. Although its logical variation, option 5 (refusal to confirm blocks in a blockchain containing transactions prohibited by OFAC, maybe from the last finalized block), is perhaps simpler. In option 5, censoring pools never validate blocks, receive heavy penalties, and have no choice but to leave the network. In this case, there is also most likely no need to conduct a UASF or hard fork.

Option 3: Create and validate OFAC blocks, even if they conflict with non-OFAC blocks

Это более экстремальный вариант, который, is likely to be perceived by a large part of the Ethereum community as an attack on the network. It can lead to a reorganization of the blockchain. However, "slashing" can still be avoided. This scenario could result in a protocol change via UASF or a hard fork and loss of collateral for staking by attacking pools. It could also lead to permanent splitting of the blockchain, especially if stablecoin custodians choose a version that complies with OFAC rules. We will not go into details.

Conclusion

We have no intention of reviewing everything here.possible options for applying censorship in Ethereum. The main message we want to convey is that censorship scenarios in proof-of-stake are more complicated than in proof-of-work. And in this regard, complexity can play both a positive and a very negative role for Ethereum.

The potential positive is thatthat regulators may not understand what action to take and therefore take less regulatory action. The potential downside is that option 2 has the potential to cause a lot of problems, even though it's a fairly mild and non-reorganizing choice that's hard to qualify as an attack on the network.

It should also be noted that these forms of censorship will likely require the creation of new client programs and a lot of technical work. As far as we know, this work has not yet been done.

In terms of the overall impact of this potential censorship and regulatory action, the most likely results over the medium term are as follows:

• increase in the average time of transaction finalization;
• de facto lack of effective censorship of target users, just a slight delay in transaction processing;
• less participation in staking by large financial institutions and generally lower levels of staking, which leads to higher profitability.

MEV auction process / Flashbots

BitMEX Research talked about MEV auctions andFlashbots in this May report. At that time, there was no clear understanding of what would happen to the MEV auction after The Merge. Over the past few months, significant progress has been made in this direction and infrastructure has been created.

The first thing to note is that afterBy activating The Merge on Ethereum, there will be a distinction between an execution client (like Geth) and a consensus client (like Prysm). Today, the runtime client does everything: processes all transactions and smart contracts, and decides which blockchain branch to follow.

After the merge, users will need to runtwo clients for tracking and verifying the blockchain: an execution client for processing transactions and a consensus client for creating blocks and determining the chain branch with the highest stake. Therefore, in anticipation of the merge, it was the execution client (Geth) that was adapted to add Flashbot functionality. After the update is activated, since the blocks are created at the consensus level, it will be the clients of this level that will need to add the Flashbot functionality.

As far as we can tell, all five competingConsensus layer clients have already implemented a system like Flashbots as a standard feature using a system called MEV-Boost. This is a little different from what we have before the merge. To run Flashbots before the merge, miners had to download a special version of Geth called MEV-Geth. Now it looks like MEV-Boost is included as standard.

It must be kept in mind that the MEV auction system hasa trusted centralized relay server, so it can be argued that including MEV-Boost in the default package can increase centralization. However, the Flashbots relay server URL does not appear to be added as a standard to the consensus layer clients we reviewed; it must be configured manually. But the URL of the Flashbots server is included in the user guides and instructions we've reviewed for setting up consensus clients. Therefore, determining how much more centralization this will bring remains an open question.

It should also be noted that, as far as we canto judge, Flashbots indicated that the relay server already complies with OFAC requirements and censors transactions. On August 17, to alleviate this problem, Flahsbots announced they were accelerating the development of an open source relay server. This should mean that more people will be able to run their relay servers and miners/stakers will be able to manually select the server of their choice. Therefore, if one server censors transactions, then users have the opportunity to switch to another.

However, as mentioned in the May BitMEX report,significant centralizing forces arise around the relay server: 1) it is difficult to manage and requires significant resources and expertise, and 2) the server operator must be trusted to avoid front-running or other dishonest actions on its part. Therefore, it can be a difficult task to come to a situation with a diverse, dynamic and large selection of relay servers. In particular, this is unlikely to happen before the merge.

New MEV-Boost architecture

There is something about the new MEV auction infrastructuremuch worse in terms of centralization and censorship resistance, even more serious than the problem with the relay server. In the May BitMEX Flashbots report, the authors wrote:

Miners participating in the Flashbots system alsomay include in their blocks any non-Flashbot transactions that they may receive from the public transaction memory pool. Miners who subscribe to receive transactions through Flashbot must run a special modified version of Geth - MEV-Geth. In our opinion, it is very important that the mining nodes also connect to the “regular” memory pool and, if possible, add these transactions to the blocks as well. This is the main counterargument against those who argue that since the Flashbots system is centralized and widely distributed among miners, Ethereum has a single point of failure.

As far as we can tell, for the newinfrastructure, this argument is no longer relevant. It became impossible to add transactions from the mempool to transactions and bundles from the MEV auction system. Block creators need to complete the block using the MEV auction system. From our point of view, this is a serious shortcoming that increases the risk of centralization. We're not sure why this decision was made, but it doesn't look like a downside to PoS by default. Perhaps MEV-Boost is being developed at an accelerated pace, and the developers simply have not had time to implement this feature yet. So in the future this feature may be added and the problem will be fixed. But, again, as far as we can tell, this is unlikely to happen before the merge.

 

BitNews disclaim responsibility for anyinvestment recommendations that may be contained in this article. All the opinions expressed express exclusively the personal opinions of the author and the respondents. Any actions related to investments and trading on crypto markets involve the risk of losing the invested funds. Based on the data provided, you make investment decisions in a balanced, responsible manner and at your own risk.

</p>