Abstract: In this piece we discuss the degree of censorship resistance in Ethereum after the merge, in the context of the recent decision by the United States Treasury’s Office of Foreign Assets Control (OFAC) to sanction the Tornado Cash contract on Ethereum. This report focuses on the technical characteristics and specifications of the Proof of Stake system and how these could interact with the sanctions, should stakers choose to comply with them. We also look at changes to the MEV auction system post merge and how this could impact the level of censorship resistance on the network. We conclude by arguing that under Proof of Stake there are a lot more complexities when it comes to censorship than in Proof of Work. We also conclude that the upgraded MEV auction architecture for the merge makes the situation materially worse, however this could be fixed in the future.
Overview
On 8th August 2022, the United States Treasury announced that the Tornado Cash mixing smart contract was sanctioned. We will not go into the rights or wrongs of that here, instead, this report will focus on some technical considerations, in particular with respect to how Ethereum will change after the merge and switch to Proof of Stake (PoS).
The first thing to note is that in either a Proof of Work (PoW) or PoS systems, the choice for miners and stakers in the face of these sanctions is not a simple binary choice. It is not a decision between: banning the OFAC transactions or ignoring the OFAC ban. There is more nuance than that. You could argue there are three major choices:
- Ignore the OFAC rules
- Refuse to include OFAC banned transactions in blocks you produce
- Refuse to build on top of a chain that includes OFAC banned transactions
Option 2 is considered a much more conservative or moderate choice than option 3. Many argue that option 2 is also entirely legitimate, afterall the producer of the block should be free to include whatever transactions they like in them. If they want to exclude certain transactions, it is their free choice. Option 3 on the other hand is a more extreme option, which many regard as an attack on the network. If those engaging in option 3 only have a minority of the hashrate, it is likely to result in a failed attempt at censorship and significant loss of capital for the would be censor. On the other hand, if the censor is in the majority and succeeds, the network is in a major crisis and has perhaps failed.
The complexities of Proof of Stake
When we consider Ethereum’s proof of stake system, the situation is even more nuanced. Rather than there being just three significant choices in the face of these regulations, we have identified at least eight choices. In reality, there are even more options, but we won’t go into them here.
1. Refuse to include “OFAC banned” transactions in blocks you produce
2. Refuse to attest to blocks which contain OFAC banned transactions
3. Produce and attest to blocks which comply with OFAC rules, even when they conflict with non-compliant blocks
4. Refuse to produce blocks on top of blocks which contain OFAC banned transactions
5. Refuse to attest to blocks in a chain which contains OFAC banned transactions
6. Refuse to include attestations to blocks with OFAC banned transactions in blocks you produce
7. Refuse to include attestations to blocks in a chain with OFAC banned transactions in blocks you produce
8. Ignore the OFAC rules
Many in the Ethereum community consider the prospect of this censorship to be a major issue. In particular, much of the stake is concentrated in large financial institutions, often with a US jurisdiction such as Coinbase. Therefore many are advocating special action, such as an emergency UASF/HF, to delete the stake of validators who engage in such censorship. Indeed, this is said to be a major advantage of PoS. Exiting from a validator pool can take a lot of time, at least several months if it’s a large amount of stake. Therefore, the Ethereum community has time to arrange a protocol change to punish the badly behaving stakers. Under PoW, it is much harder to punish only the badly behaving miners and instead, if the community goes for a protocol change, all miners may need to be punished, not just the nefarious ones.
Option 1 – Refuse to include “OFAC banned” transactions in blocks you produce
Anyway, as we mentioned above, what kind of censorship the stakers engage in is highly nuanced. Option 1 above is quite mild. In our view it is highly unlikely that there would be a UASF/HF in the event a large staker chose option 1. The only real impact here would be a small loss in earnings for the censor, which may lead to a loss in market share. Even if these censors had 50% control of the total stake, this could mean that those dealing with Tornado Cash would only have to wait an expected 24 seconds for their transaction to get into the block, rather than 12 seconds. (Assuming the fee was high enough to get into the next block). This does not seem like much disruption. At the same time, block producers are free to put what they like in their blocks. This action may therefore be seen as legitimate and a UASF/HF in response could be considered unjustified and unethical. In our view, this approach (option 1) may be most likely in the short to medium term. This is of course speculation, but Coinbase and the US Treasury could reach a compromise and go for option 1. However, explaining these nuances to regulators may be extremely difficult.
Option 2 – Refuse to attest to blocks which contain OFAC banned transactions
Option 2, refusing to attest to blocks with OFAC banned transactions, is far more complex and has a lot of implications. Firstly, there is the argument that this option is theoretically incorrect. Although technically you can argue that, when you attest to a block, you are choosing just one block, the head block. If that block has OFAC banned transactions, you may look to have breached OFAC rules. On the other hand, substantively, that is not really how the staking process works. The staker is voting on a source block, a target block and a head block, and in theory, what the staker is actually attesting to is all transactions between the last finalised block and the head block. The fact that the head block is referenced in the attestation is merely a technicality. Indeed, for example, a chain split could have occurred three blocks in the past, there could then be two competing chains of equal length and then the validator has to choose which side to pick, by choosing between two head blocks at the same slot. In this scenario, why should OFAC only care about the transactions in the head block? Shouldn’t they also care about the transactions between the chain split and the head block, because this is what the vote is actually deciding on? Or course we highly doubt that US Treasury officials are currently grappling with these confusing questions. However, it does illustrate that perhaps option 2 is somewhat theoretically flawed.
Despite this flaw, if option 2 is chosen, on the surface it might seem like a mild choice, like option 1. The action does not involve causing chain re-organisations and a staker should be free to choose what blocks they attest to, it’s their free choice. Therefore this form of censorship can be seen as legitimate and a UASF/HF in response can be seen as unfair or to extreme, just like option 1.
However, if we assume that most blocks contain OFAC banned transactions, the consequences of option 2 can be quite severe. The validators engaging in this censoring practice would therefore rarely participate in the network and get zero earnings. Actually they would have to pay penalties for inactivity. This would make staking almost totally pointless. Why just sit there getting fined when you could just exit? Therefore, in our view, a UASF/HF may neither be ethical nor necessary in response to the threat of a small number of validators choosing option 2. It should also be noted that even before the merge, you can exit the staking pool and therefore you can avoid the inactivity fee. It is just that you can’t withdraw these funds back to the execution layer. This full withdrawal may be available around 12 months after the merge, the so-called 2nd merge.
If the censoring validator pools are large enough, the entire network could fail to finalise blocks and essentially the network would stop working. The large inactive pools could therefore get larger and larger fines, increasing as time progresses. Therefore, as before, there is almost no point choosing option 2, instead validators might as well exit the system. On the other hand, if these pools were large and also engaging in censorship option 1, the situation can be a bit more murky. Now, there are OFAC compliant blocks that come up every now and then, and the censoring pools may be able to attest to some blocks, when the opportunity arises, if the censor is in the correct committee. It is difficult to determine what the outcome here would be. Earnings of the censoring validator pools would be negatively impacted, however they could still earn money in some periods, it may depend on the percentage split between censoring and non-censoring pools. Even if the censoring pools have a strong majority, it is not clear if users using Tornado Cash actually lose out, they may need to wait a little bit longer for a confirmation, but then finalisation should occur just as fast as for everyone else. Therefore the censorship itself may still be largely ineffective. It is also possible the network is slower at finalising blocks, which could be a problem. It may therefore be possible that the Ethereum developers and community choose a UASF/HF if this occurs. However, in our view, a protocol change here is still unlikely and we are not convinced a UASF/HF would be justified.
You can also do some basic maths here. If 50% of the stake is engaging in option 1 and option 2 censorship, the situation could be as follows:
- 50% of the stakers (the “well behaved” stakers) attest 100% of the time
- 50% of the stakers (the censors) attest 50% of the time, only on the OFAC compliant blocks
- The average network attestation participation rate is therefore 75%
If 100% of the validators censor, all blocks are OFAC compliant and all blocks can be attested to. If 0% of validators censor, all blocks can be attested to. The 50:50 case, maybe the “worst case”, results in a potential 75% attestation rate. 75% is therefore the lowest average attestation participation rate one can get in this scenario. Since 75% is above 66.7%, it looks like the chain should be somewhat viable and continue to move forwards. Although of course there are a lot of assumptions in these calculations, at it would never work out perfectly like this in practise. It seems that in these scenarios, whatever the percentage breakdown, as long as a significant proportion of validators are honest, the censorship will not be especially effective.
Theoretical average network attestation participation rate
Source: BitMEX Research
Notes: Assumes that there is always a transaction the censor would ban available to be included in the block. Assumes the censors: i. never include banned transactions in thier blocks, and ii. Never attest to a block with a banned transaction
The above chart illustrates that there is the possibility of an equilibrium point, in the middle, where the network continues along, with some censorship. If the proportion of censoring validators is too low, for example below 25%, the inactivity penalty may be too high and the censors would be forced to leave. Then 100% of the remaining validators would then be honest. Other than this scenario, it can be argued that the network could continue for a while with this limited censorship. There could in theory be no need for anyone to fix anything. However, censors would still earn a lower yield and may at some point want to leave.
What the above shows is that option 2 is potentially quite messy and confusing. While the logical variant of it, option 5, refusing to attest to blocks in a chain which contain OFAC banned transactions, perhaps since the last finanlised block, is perhaps more simple. With option 5, censoring pools never attest to blocks, they just get large fines and are left with no other reasonable choice but to leave. A UASF/HF is therefore not likely to be necessary.
Option 3 – Produce and attest to blocks which comply with OFAC rules, even when they conflict with non-compliant blocks
This option is more extreme and is likely to be regarded as an attack by many in the Ethereum community. It could cause chain re-organisations. However, slashing may still be avoidable. This action may result in a UASF/HF protocol change and a loss of stake for the attacking pools. It could also cause a persistent chain split, especially if stablecoin custodians choose the OFAC compliant chain. We will not go into details here.
Conclusion
We are not going to cover all of the censorship options in this report. The point we are trying to make is that the censorship scenarios are more complex than in Proof of Work. This complexity could turn out to be a positive or indeed a negative, for Ethereum. A potential positive is that regulators may not know what action to take, which could result in less regulatory action. A potential negative is that option 2 could cause a lot of problems, even though its only quite a mild choice which doesn’t cause re-orgs and is therefore hard to frame as an attack. It should also be noted that these forms of censorship probably require new clients and a lot of technical work. As far as we know, this work has not been done.
As for the overall impact of this potential censorship and regulatory action. The most likely outcomes in the medium term could be as follows:
- Slower network finalisation times
- No actual effective censorship of targeted users, just a slightly delayed experience
- Less staking from large financial institutions and lower overall levels of coins staking, resulting in higher yields
MEV Auction Process/Flashbots
We previously explained MEV auctions/Flashbots in our report back in May 2022. At that time there was no clear plan as to what would happen to the MEV auction process after the merge. In the last few months significant progress has been made and infrastructure has been built. The first thing to note is that after the Ethereum merge, there is a distinction between an execution layer client (e.g. Geth) and a consensus layer client (e.g. Prysm). Currently, the execution layer client does everything, processes all transactions and smart contracts and also decides which chain to follow. After the merge, users will need to run two clients to follow and validate the chain, the execution client to process transactions and the consensus client to produce blocks and determine the chain with the most stake. Therefore, pre-merge, it is the execution client (Geth) that was adapted to add Flashbot functionality. After the merge, since it’s the consensus layer that produces blocks, it is the consensus layer clients that will need to add Flashbot type functionality.
As far as we can tell, all five of the competing consensus layer clients have already implemented a Flashbots type system as a standard feature, using a system called MEV-Boost. This is slightly different than in the pre-merge world. To run Flashbots prior to the merge, miners had to download a special version of Geth, called MEV-Geth. Now, MEV-Boost seems to be included as standard. Remember, the MEV auction system has a trusted centralised relay server, therefore one could argue including MEV-Boost as standard could increase centralisation. However, the Flashbots relay server URL does not appear to be included as standard in the consensus layer clients we have looked at, instead it needs to be manually configured. The URL to the Flashbots server is however included in the user guides and set up instruction pages we have looked at for the consensus layer clients. Therefore, determining how much of an increase in centralisation this is, is an open question.
It should also be noted that, as far as we can tell Flashbots indicated that the relay server is already OFAC compliant and censoring transactions. On 17 August 2022, to help mitigate this issue, Flahsbots announced that it is accelerating the process of making the relay server code open source. This should mean more people can run relay servers and then miners/stakers can manually choose which relay to select. Therefore if one relay server engages in censorship, users can switch to another one. However, as we mentioned in our May 2022 report, there are many centralising forces around the relay server: i. Running it is highly complex and requires significant resources and expertise, and ii. The server operator must be trusted, to make sure it doesn’t front run searchers or engage in other dishonest action. Therefore, reaching a destination where there is a diverse, vibrant and large choice of relay servers, may be challenging. In particular, this is not likely to happen before the merge.
The New MEV-Boost Architecture is “All Or Nothing”
There is something about the new MEV auction infrastructure we think is far worse from a centralisation and censorship resistance perspective, even more significant than the relay server issue. In our May 2022 Flashbots report, we said:
The miners participating in the Flashbots system are also free to include any non-Flashbot transactions in their blocks, which they can potentially obtain by also connecting to the public transaction memory pool. Miners subscribing to Flashbot transactions are required to run a special modified version of Geth, called MEV-Geth. In our view it is critical that the mining nodes also connect to the “normal” memory pool and consider adding these transactions. This is a major counterpoint to any that would claim that since Flashbots is centralised and widely adopted by the miners, Ethereum therefore has a single point of failure.
As far as we can tell, this no longer appears to be the case with the new infrastructure. It is no longer possible to add transactions using the traditional method from the memory pool, to the transactions and transaction bundles from the MEV auction system. It now appears to be all or nothing. Block producers have to use the entire block built by the MEV auction system. In our view this is a major weakness and increases the centralisation risk. We are unsure why this is the case, however, this does not appear to be an inherent weakness with PoS. It may simply be that MEV-Boost is developing according to tight time schedules and has not got around to implementing this feature yet. Therefore at some point in the future, this functionality could be added and this major issue could be fixed. Although again, this is not likely to happen before the merge as far as we can tell.
Related
The post appeared first on Blog BitMex
