BitMex: OFAC Sanctions VS Ethereum PoS Technical Nuances

In this article, I discuss the level of censorship resistance for a merged Ethereum in the context of the recent decision by the U.S. Department of the Treasury’s Office of Foreign Assets Control (OFAC) to approve the Tornado Cash contract on Ethereum. This report focuses on the technical features and specifications of proof-of-stake systems and how these interact with sanctions if stakeholders choose to comply with them. We also examine changes to the post-merger MEV auction system and how this will affect censorship resistance levels on the network. We conclude that under PoS, censorship is much more complicated than PoW. We also conclude that the upgraded MEV auction architecture for merging makes the situation worse.

Overview

On August 8, 2022, the U.S. Treasury Department announced the approval of the Tornado Cash hybrid smart contract. We won’t discuss right and wrong here, instead, this report will focus on some technical considerations, especially regarding how Ethereum will change after the merger and switch to Proof of Stake (PoS).

The first thing to note is that the choice of miners and stakers when faced with these sanctions is not a simple binary choice, whether in a proof-of-work (PoW) or PoS system. This is not a decision: ban OFAC transactions or ignore OFAC bans. There are more nuances than that. There are arguably three main options:

  1. Ignoring OFAC rules
  2. Refuse to include OFAC prohibited transactions in your generated blocks
  3. Refuse to build on chains that contain OFAC-prohibited transactions

Option 2 is considered a more conservative or moderate option than Option 3. Option 2 is also considered perfectly legal by many, after all the producers of blocks should be free to include any transactions they like in them. If they want to exclude certain deals, it’s their free choice. Option 3, on the other hand, is a more extreme option and is considered by many to be an attack on the network. If those participating in option 3 have only a small amount of computing power, it is likely to fail the review and result in a large capital loss for the reviewer. On the other hand, if the censors are in the majority and succeed, the network is in a major crisis and may have failed.

Proof of Stake Complexity

The situation is more nuanced when we consider Ethereum’s proof-of-stake system. Faced with these regulations, we have identified not only three important options, but at least eight options. Actually, there are many more options, but we won’t discuss them here.

1. Refuse to include “OFAC Prohibited” transactions in your generated blocks

2. Refuse to prove blocks containing OFAC prohibited transactions

3. Produce and certify OFAC-compliant blocks even if they conflict with non-compliant blocks

4. Refuse to generate blocks on top of blocks containing OFAC prohibited transactions

5. Refuse to prove blocks in the chain that contain OFAC-prohibited transactions

6. Refuse to include proofs of blocks that OFAC prohibit transactions in the blocks you generate

7. Refuse to include in your generated blocks proofs of on-chain blocks that OFAC prohibits transactions

8. Ignoring OFAC Rules

Many in the Ethereum community see the prospect of this censorship as a major concern. In particular, the majority of equity is concentrated in large financial institutions, often in US jurisdictions such as Coinbase. So many advocate special action, such as emergency UASF/HF, to remove the stakes of validators participating in such censorship. In fact, this is said to be a major advantage of PoS. Withdrawing from the validator pool can take a long time, at least a few months if there is a lot of staking. Therefore, the Ethereum community has time to schedule changes to the protocol to punish misbehaving stakers. Under PoW, it is much harder to punish only misbehaving miners, on the contrary, if the community changes the protocol, all miners may need to be punished, not just evil miners.

Option 1 – Refuse to include “OFAC Prohibited” transactions in your generated blocks

In any case, as we mentioned above, what kind of scrutiny stakers conduct is very nuanced. Option 1 above is fairly modest. In our opinion, UASF/HF is unlikely if large stakers choose option 1. The only real impact here is a small loss in the earnings of the examiners, which could lead to a loss of market share. Even if these examiners control 50% of the total stake, this could mean that those dealing with Tornado Cash just have to wait Instead of 12 seconds, their transaction would enter the block at the expected 24 seconds. (Assuming the fee is high enough to get to the next block). This doesn’t seem to interfere much. At the same time, block producers are free to put what they like into their blocks. Therefore, the action may be considered legal, and the UASF/HF in response may be considered unreasonable and unethical. We believe that this approach (option 1) is likely most likely to emerge in the short to medium term. This is of course speculation, but Coinbase and the U.S. Treasury may compromise and choose option 1. However, explaining these nuances to regulators can be very difficult.

Option 2 – Reject blocks that prove to contain OFAC prohibited transactions

Option 2, refusing to prove blocks with OFAC-banned transactions, is much more complicated and has many implications. First, some argue that this option is theoretically incorrect. Although technically you can argue that when you prove a block, you only choose one block, the head block. If the block has OFAC prohibited transactions, you may appear to be violating OFAC rules. On the other hand, this is not how the staking process really works, per se. The stakers are voting on the source block, the destination block, and the header block, and in theory, what the staker is actually proving is all transactions between the last finalized block and the header block. The fact that the header block is referenced in the proof is only technical. In fact, for example, a chain split could happen in the last three blocks, then there could be two competing chains of equal length, and then the validator would have to choose which side to choose by choosing between two header blocks in the same slot . In this case, why does OFAC only care about transactions in the header block? Shouldn’t they also care about chain splits and transactions between header blocks, since that’s what the vote actually decides? Of course, we highly suspect that U.S. Treasury officials are currently grappling with these puzzling questions. However, it does illustrate that option 2 may be theoretically flawed. Why should OFAC only care about transactions in the header block? Shouldn’t they also care about chain splits and transactions between header blocks, since that’s what the vote actually decides? Of course, we highly suspect that U.S. Treasury officials are currently grappling with these puzzling questions. However, it does illustrate that option 2 may be theoretically flawed. Why should OFAC only care about transactions in the header block? Shouldn’t they also care about chain splits and transactions between header blocks, since that’s what the vote actually decides? Of course, we highly suspect that U.S. Treasury officials are currently grappling with these puzzling questions. However, it does illustrate that option 2 may be theoretically flawed.

Despite this flaw, if option 2 is chosen, on the face of it, it appears to be a moderate choice, just like option 1. This action does not involve causing a chain reorganization, and stakers should be free to choose the blocks they are proving, it is their free choice. Therefore, this form of censorship can be considered legitimate and the UASF/HF response can be viewed as unfair or extreme, just like Option 1.

However, if we assume that most blocks contain transactions prohibited by OFAC, then the consequences of option 2 can be very severe. As a result, validators participating in this censorship practice will rarely participate in the network and receive zero returns. In effect, they will have to pay a fine for inactivity. This would make staking almost completely meaningless. Why sit there and get fined when you can quit? Therefore, in our view, the UASF/HF threat to a minority of validators choosing option 2 may be neither ethical nor necessary. It should also be noted that you can exit the staking pool even before merging, so you can avoid inactivity fees. It’s just that you can’t withdraw those funds back to the executive layer. This complete withdrawal could be around 12 months after the merger, the so-called second merger.

If the pool of censorship validators is large enough, the entire network may not be able to finalize blocks and basically the network will stop working. As a result, large inactive pools may receive larger and larger penalties, increasing over time. So, as before, it makes little sense to choose option 2, instead, the validator might as well quit the system. On the other hand, if these pools are large and also participate in reviewing option 1, the situation may be more ambiguous. Now, from time to time, OFAC-compliant blocks appear, and if the censors are on the right committee, the censorship pool may be able to attest to certain blocks when the opportunity arises. It’s hard to tell what the outcome here will be. The earnings of the censorship validator pool will be negatively affected, but they can still make money during certain periods, which may depend on the percentage split between censorship and non-censorship pools. Even with the censorship pool in the majority, it’s unclear if users using Tornado Cash actually lost, they may have to wait longer for confirmation, but finalization should be as fast as everyone else. Thus, censorship itself may remain largely ineffective. It is also possible that the network is slower in completing blocks, which could be a problem. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. It may depend on the percentage split between censored and non-censored pools. Even with the censorship pool in the majority, it’s unclear if users using Tornado Cash actually lost, they may have to wait longer for confirmation, but finalization should be as fast as everyone else. Thus, censorship itself may remain largely ineffective. It is also possible that the network is slower in completing blocks, which could be a problem. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. It may depend on the percentage split between censored and non-censored pools. Even with censorship pools majority, it’s unclear using Tornado Cash of users really lose, they may have to wait longer to confirm, but finalization should be as fast as everyone else. Thus, censorship itself may remain largely ineffective. It is also possible that the network is slower in completing blocks, which could be a problem. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. They may have to wait longer for confirmation, but finalization should be as quick as everyone else. Thus, censorship itself may remain largely ineffective. It is also possible that the network is slower in completing blocks, which could be a problem. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. They may have to wait longer for confirmation, but finalization should be as quick as everyone else. Thus, censorship itself may remain largely ineffective. It is also possible that the network is slower in completing blocks, which could be a problem. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. They may have to wait longer for confirmation, but finalization should be as quick as everyone else. Thus, censorship itself may remain largely ineffective. It is also possible that the network is slower in completing blocks, which could be a problem. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. They may have to wait longer for confirmation, but finalization should be as quick as everyone else. Thus, censorship itself may remain largely ineffective. It is also possible that the network is slower in completing blocks, which could be a problem. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. Therefore, if this happens, Ethereum developers and the community may choose UASF/HF. However, a protocol change here is still unlikely in our opinion and we do not believe UASF/HF is justified. 

You can also do some basic math here. If 50% of the shares participate in the Option 1 and Option 2 review, the situation may be as follows:

  1. 50% of pledgers (“well behaved” pledgers) testify 100% of the time
  2. 50% of stakers (censors) attest 50% of the time, only on OFAC compliant blocks
  3. As a result, the average network certification participation rate is 75%

All blocks are OFAC compliant and all blocks are provable if reviewed by 100% of validators. All blocks can be proven if 0% of validators censor. The 50:50 case, perhaps the “worst case”, results in a potential 75% proof rate. Therefore, 75% is the lowest average proof participation rate that can be obtained in this situation. With 75% above 66.7%, it looks like the chain should be somewhat viable and continue moving forward. Of course, there are a lot of assumptions in these calculations, because in practice it will never work perfectly like this. It seems that in these cases, regardless of the percentage decomposition, censorship will not be particularly effective as long as a large percentage of validators are honest.

ND6JJI62G6QtgSGBJg1En5TK9qi08mVomnZMYY2U.png

Theoretical Average Network Certification Participation Rate Source: BitMEX Research

Note: Suppose there is always a transaction that is banned from the block by the censors. Assume that censors: i. never include forbidden transactions in their blocks, and ii. never use forbidden transactions to prove a block.

The diagram above illustrates the possibility that there is an equilibrium point in the middle, where the network continues to function, with some scrutiny. If the percentage of censorship validators is too low, say below 25%, the inactivity penalty may be too high and the censors will be forced to leave. Then 100% of the remaining validators will be honest. Aside from that, it’s fair to say that the network can survive this limited censorship for a while. In theory, no one needs to fix anything. However, examiners are still less profitable and may want to leave at some point.

There is a point of view in favor of censors winning. If there are some censorship provers, even a small number, block producers may worry that if they include transactions prohibited by OFAC, they have less chance of getting on the winning chain. Therefore, using a “least forgiving victory” type of logic, many block producers can comply with OFAC sanctions just to be on the safe side. Sanctions may have some effect.

Shown above is that option 2 can be very confusing and confusing. While its logical variant, option 5, rejects attesting blocks in chains that contain OFAC-prohibited transactions, possibly since the last completed block, it may be simpler. With option 5, censorship pools will never prove blocks, they will just receive huge fines and have no reasonable choice but to leave. Therefore, UASF/HF may not be needed.

Option 3 – Generate and certify OFAC-compliant blocks even if they conflict with non-compliant blocks

This option is extreme and is likely to be seen as an attack by many in the Ethereum community. It can lead to linkage recombination. However, cuts are still avoidable. This action may result in UASF/HF protocol changes and loss of stake in the attack pool. It could also lead to ongoing chain splits, especially if stablecoin custodians choose an OFAC compliant chain. We won’t go into details here.

in conclusion

We will not cover all review options in this report. The point we’re trying to make is that censorship scenarios are more complex than proof-of-work. For Ethereum, this complexity could turn positive, or even negative. A potential positive is that regulators may not know what to do, which could lead to less regulatory action. One potential downside is that option 2 can cause a lot of problems, although it’s only a very mild option that doesn’t lead to reorganization, so it’s hard to see it as an attack. It should also be noted that these forms of review may require new clients and a lot of technical work. As far as we know, this work is not yet complete.

As for the overall impact of this potential scrutiny and regulatory action. The most likely outcomes in the medium term are as follows:

  • Slow network completion time
  • There is no actual and effective review of target users, but the experience is slightly delayed
  • Larger financial institutions have less staking and overall lower levels of token staking, leading to higher yields

MEV auction process/Flashbots

We previously explained MEV auctions/Flashbots in our May 2022 report. At the time, there were no clear plans for what would happen to the combined MEV auction process. Over the past few months, significant progress has been made and the infrastructure has been built. The first thing to note is that after the Ethereum merger, there is a distinction between execution layer clients (e.g. Geth) and consensus layer clients (e.g. Prysm). Currently, the execution layer client does everything, handles all transactions and smart contracts, and decides which chain to follow. After the merger, users need to run two clients to track and verify the chain, execute the client to process transactions, and the consensus client produces blocks and determines the chain with the most stake. Therefore, before merging, the execution client (Geth) was adapted to add Flashbot functionality. After the merger,

To our knowledge, all five competing consensus layer clients have implemented the Flashbots type system as a standard feature using a system called MEV-Boost. This is slightly different from the pre-merger world. To run Flashbot before merging, miners must download a special version of Geth called MEV-Geth. MEV-Boost seems to be standard now. Keep in mind that the MEV auction system has a trusted centralized relay server, so one might argue that making MEV-Boost a standard increases centralization. However, the Flashbots relay server URL does not appear to be included as standard in the consensus layer clients we looked at, and instead requires manual configuration. However, the URL for the Flashbots server is included in the user guide and setup instructions pages, and we’ve looked at the consensus layer client. It is therefore an open question to determine how much centralization has increased.

It should also be noted that, as far as we know, Flashbots says that the relay server is already OFAC compliant and censors transactions. On August 17, 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 that more people can run relay servers, and then miners/stakers can manually choose which relay to choose. So if one relay server is censoring, the user can switch to another relay server. However, as we mentioned in our May 2022 report, there is a lot of concentration around relay servers: i. Running it is complex, requires a lot of resources and expertise, and ii. the server operator must be trusted to ensure it does not preempt searchers or engage in other dishonest practices. As such, reaching a destination with a diverse, vibrant, and large selection of relay servers can be challenging. In particular, this is unlikely to happen before the merge.

The new MEV-Boost architecture is “all or nothing”

From a centralization and censorship resistance perspective, we believe there are some issues with the new MEV auction infrastructure, even more so than the relay server issue. In our May 2022 Flashbots report, we said:

Miners participating in the Flashbots system are also free to include any non-Flashbot transactions in their blocks, which they can also obtain by connecting to a public transaction mempool. Miners subscribing to Flashbot transactions need to run a special modified version of Geth called MEV-Geth. In our opinion, it is critical that mining nodes also connect to the “normal” mempool and consider adding these transactions. This is the main antithesis of anyone claiming that Ethereum has a single point of failure because Flashbots are centralized and widely adopted by miners.

As far as we know, this no longer seems to be the case with the new infrastructure. It is no longer possible to add transactions from the mempool to transactions and transaction packs from the MEV auction system using traditional methods. Right now, it’s all or nothing. Block producers must use the entire block constructed by the MEV auction system. In our view, this is a major weakness that increases the risk of concentration. We are not sure why this is the case, however, this does not appear to be an inherent weakness of PoS. This may simply be because mev-boost is being developed on a tight schedule and this feature has not yet been implemented. So, at some point in the future, this feature can be added and this major issue can be fixed. Although again, as far as we know, this is unlikely to happen before the merger.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/bitmex-ofac-sanctions-vs-ethereum-pos-technical-nuances/
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.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-08-25 10:47
Next 2022-08-25 10:49

Related articles