Skip to content

Instantly share code, notes, and snippets.

@karalabe
Last active June 5, 2024 17:35
Show Gist options
  • Save karalabe/4313ece67b528113ea72388ac2df25d8 to your computer and use it in GitHub Desktop.
Save karalabe/4313ece67b528113ea72388ac2df25d8 to your computer and use it in GitHub Desktop.
Censorship eviction

[This is a 60 minute start-thinking to finish-writing braindump. Evaluate the idea, not all the unspecced details.]

Mandated public transaction inclusion

Currently Ethereum isn't really (strongly) censorship resistant, because there's no guarantee that a transaction will get included on chain, independent of how much it pays. An inclusion list proposal was made, but seems to be conflicty with account abstractions and has non trivial protocol consequences.

This is a proposal to make the contents of the public transaction pool influece the fork choice. Consider all publicly known transactions "mandated" to be included in the next block. Of course, as a block has limited capacity, the mandate only applies to those transactions that fit, ordered by priority fee. Also, since "all public transactions" is fuzzy, the mandate acts as a soft rule, not a consensus one.

Transaction mandates

There is no global view of the mempool, so each node needs to individually decide itself what is and isn't mandated to be included. As long as the nodes form a healthy P2P network, each one of them should already be tracking the best set of (publicly broadcast) transactions that could be included in the next block(s).

Transaction pools across peers, however, do have a certain level of dissonance. Freshly created transactions take time to propagate, and old transactions get evicted with different timings. As such, a mandates cannot be made across the whole pool, rather only a smaller - but reasonable - subset that is guaranteed to be stable across the network. The proposal is to only mandate transactions older than X (e.g. 1 block) and not older than Y (e.g. 1 epoch). X needs to cover all network propagation delays, whilst Y needs to cover client / config differences. From a censorship prevention perspective, however, this is a realistic limitation: the aim is to get the transaction included reasonably timely if it's willing to pay the priority, but don't latch onto it indefinitely.

Mandate inclusion

Local validators continue to create blocks as usual - financially motivated - applying transactions from their pool, ordered by priority fees. When receiving remote blocks, validators cross reference the set of bundled transactions with their local set of "mandated" transactions, and only attest blocks where no locally mandated transaction could have been inserted whilst honoring the priority fee ordering.

If a validator decides not to attest a certain block due to a mandate violation, and enough validators refused to also attest the same block for the same reason across the network, then the next validator can consider the slot missed and create a new original block on top of the previous slot. This effectively evicts blocks from the network that the majority of the validators considered to be violating the inclusion mandates.

This idea is a behavioral solution, where validators force each other not to censor, but there is no consensus rule to do so. The censored blocks are considered still valid by the protocol, but would end up being ejected from the network, forcing validators to include all transactions or have their blocks orphaned.

The idea applies to MEV bundlers equally, without and negative exernalities. As long as they honour the priority fee orderings and leave no fee-gaps for mandated transactions, they can still add arbitrary other transactions in between for their MEV purposes.

Fork or no fork

This proposal would not require a hard fork as there are no consensus changes involved, but it does imply a behavioral change across the board, so we could consider it a gradually rolled out soft fork. First of its kind for Ethereum.

Caveats

Q: What happens if the majority does not run the mandate proposal?
A: The censoring blocks will get attested as usual and the chain chugs along.

Q: Won't the minority validators skipping attestations just be penalized?
A: During a rollout period we could run the mandate enforcement only on sparse blocks and gradually ramp up to all blocks, giving people time to update.

Q: What happens if the network never reaches the 50% mandators to start evicting censored blocks?
A: Then you know Ethereum is already captured and we can just close shop now.

Q: Doesn't this effectively force miners to assemble blocks in a very specific order?
A: Yes, it does. But local block builders already do it like that, acting as "rational economic actors", and MEV bundlers can inject arbitrary priority fees (they get it back), so they can also make blocks looking "economically rational" from a ti pperspective.

@mteam88
Copy link

mteam88 commented May 17, 2024

Few thoughts:

  1. This conflicts somewhat with EIP-1559 pricing dynamics. If a user can always get a transaction in a soon (maybe 1-3) block when submitting a valid transaction (base fee > block base fee) then priority fees are pointless. Correct me if I'm wrong.
  2. The constraint on ordering for block builders severely limits the sequencing value of a block. So much so that it will likely hurt the profits of proposers. We shouldn't rely on proposers to be altruistic to achieve CR (see forward ILs).
  3. It is impossible to prove that a certain block proposer didn't see a transaction that they don't include - and there are plenty of legitimate reasons that a proposer might not see a certain transaction (esp. on low-bandwith servers). This means blocks would get ejected on accident in some scenarios.

@SCBuergel
Copy link

only attest blocks where no locally mandated transaction could have been inserted

But a strictly greedy validator wouldn't follow that rule because they miss out on attestation rewards, right? Since the majority of validators are commercial operations and competitive on APY I can imagine it will be hard to get them to comply with this anti-incentivized but ethical strategy. A point in case is how long it took to even start moving the needle towards some level of client diversity. So I'd not imagine this to change anything for the better.

@uri-bloXroute
Copy link

Ari Jules had a similar yet a bit more convoluted for Tx inclusion AND ordering called Themis.
TLDR: attesters send the Tx they see (in order) to the leader, who can only aggregate their signatures to produce the block (can't reorder / inject Tx).

my own additions were:

  • leader can broadcasts real-time pre-confs as it receives these updates
  • users can avoid frontrunning by sending their Tx to the attesters:
  • measure latency to multiple attesters
  • send Tx to the furthest attesters first, gradually to the closer ones, over the course of ~80 ms
  • even if a n attester receives your Tx and wants to front run you, it won't be able to get to the other side of the world fast enoughto beat your Tx due to speed of light limit

I admit your idea for inclusion only is a lot cleaner and more practical

@caiosabarros
Copy link

A very high-level incentive for such mandates would be to have two set of proposers - the 32 eth stakers and the S eth stakers (S <32) - i.e, the ones that had received a discount for staking - for example, instead of staking 32 eth, they'd be staking S eth (S<32) and then they would be chosen from X to X blocks and the mandated transactions would be sent by them, forcibly. The incentive here would be the discount for them - which could become a broader incentive to everyone else. For those trying to get the most MEV rewards, they'd still be part of the common set of validators, but they'd be willing to put on stake their 32 eth. Rewards are continue to drive behavior in the network, however, we can mkae it easier for those who want to strengthen CR. Also, something of this sort allows more diversity in the network and enhances decentralization.

@karalabe
Copy link
Author

@mteam88

  1. This conflicts somewhat with EIP-1559 pricing dynamics. If a user can always get a transaction in a soon (maybe 1-3) block when submitting a valid transaction (base fee > block base fee) then priority fees are pointless. Correct me if I'm wrong.

I think you're wrong. This "mandate" would still require adhering to the basefee, and any transaction that does adhere to the basefee would be ordered greedily via their tip. Only the mandates that "fit" into the block according to "economically rational actor" rules would be required to be moved in. This proposal would not "guarantee" you a slot just because you made a cheap transaction, but it would guarantee you a slot if your transaction is legitimately valuable enough to have priority in the next (X blocks).

  1. The constraint on ordering for block builders severely limits the sequencing value of a block. So much so that it will likely hurt the profits of proposers. We shouldn't rely on proposers to be altruistic to achieve CR (see forward ILs).

I think the truth is in the middle. An MEV extractor can add front/back-running transactions at arbitrary price points (they are mining it after all, they get the tip back). So if a juicy transaction fits into the block naturally, then they can MEV-it as usual. Now, where they would do lose some is that they would not be able to include underpriced transactions that make no economic sense outside of MEV, but contain some thing that they can make money off of. That's the cost of censorship resistance using up block gas.

So 1) yes, it does somewhat impact MEV miners, but b) who are we catering the network for? The proposal does not "kill" MEV extraction at all, and the juicy transaction left on the table remains there and can still be included later, so it's not lost "value" either. Of course and censorship resistance is going to mess with MEV a bit. Don't see it as bad though.

  1. It is impossible to prove that a certain block proposer didn't see a transaction that they don't include - and there are plenty of legitimate reasons that a proposer might not see a certain transaction (esp. on low-bandwith servers). This means blocks would get ejected on accident in some scenarios.

The proposal would be to have reasonable propagation timing thresholds to make this improbable: allow at least X time after seeing a tranasction before mandating it; and don't mandate over Y time if it wasn't economically viable to include. The observation here is that if a transaction is valuable enough according to its tip, then validators completely oblivious to this mandates would still include it. This whole mining strategy completely follows what's the best interest for a naive miner.

But yes, it would mean that clients would need to put some effort into making their transaction pools a bit tighter and not yolo it. I think requiring validators to be able to track the best X transactions in the network is not a high ask.

@karalabe
Copy link
Author

@SCBuergel

But a strictly greedy validator wouldn't follow that rule because they miss out on attestation rewards, right? Since the majority of validators are commercial operations and competitive on APY I can imagine it will be hard to get them to comply with this anti-incentivized but ethical strategy. A point in case is how long it took to even start moving the needle towards some level of client diversity. So I'd not imagine this to change anything for the better.

The ramp-up is an interesting question, my proposal would be to have an gradual buildup where initially only "rare" blocks are mandated to be censorship resistant, so the lack of a consensus on this doesn't meaningfully impact anyone; and when that slot seems to be observed to be truly honored, then gradually ramp up.

So as long as validators are willing to add censorship resistance, I think the rollout can be made to be non-painful to anyone. If validators decide that they DO NOT want censorship resistance, then that's a different story... but then I consider the network captured.

@karalabe
Copy link
Author

@uri-bloXroute

I admit your idea for inclusion only is a lot cleaner and more practical

I strive to keep things as simple as possible. I'm definitely not saying that my proposal is / or ever will be workable, so definitely people need to tear it apart. BUT by keeping the proposal ultra dumb and simple, it's at least easy to rationalise whether it will work or not. I'm always weary about complex stuff because you can never truly see across all the hidden inter-dependencies and side effects.

@karalabe
Copy link
Author

@caiosabarros

A very high-level incentive for such mandates would be to have two set of proposers - the 32 eth stakers and the S eth stakers (S <32) - i.e, the ones that had received a discount for staking - for example, instead of staking 32 eth, they'd be staking S eth (S<32) and then they would be chosen from X to X blocks and the mandated transactions would be sent by them, forcibly. The incentive here would be the discount for them - which could become a broader incentive to everyone else. For those trying to get the most MEV rewards, they'd still be part of the common set of validators, but they'd be willing to put on stake their 32 eth. Rewards are continue to drive behavior in the network, however, we can mkae it easier for those who want to strengthen CR. Also, something of this sort allows more diversity in the network and enhances decentralization.

I have to admit I'm not really following your idea here (unsure what S < 32 stakers are). My gut reaction by the bits I understood is that I don't think making such a mechanism too smart is a good idea. If it's something simple, it's effects can be understood, it's risks can be understood, etc. When you start making it "smart", it also start so become much more easily/sneakily gameable.

@koeppelmann
Copy link

IMO it is a solid proposal. It might make re-orgs slightly more likely but this is IMO an acceptable price to pay.

@FabrizioRomanoGenovese
Copy link

This is a good proposal, but I'll make the same observation I made for inclusion lists: We should see how this stands from a legal standpoint. Let me elaborate. My main beef about inclusion lists is that they may not be tenable from a legal standpoint. In a nutshell, we know very well how 'forcing someone to commit a crime' can be considered a crime itself in many circumstances and jurisdictions. For instance, by adding a Tornado cash tx to an inclusion list may in itself be considered as a non compliant move, either now or in the future. This is probably too much of a possible legal risk to undertake for some node operators. My suspicion is that, therefore, inclusion lists may not end up being used as much as people imagined they would.

Here, you are suggesting a form of 'behavioral consensus' where validators keep a local list of 'mandated txs' and use it do decide on the matter of attesting. I think that for this to be considered a good idea for censorship resistance we should keep into account:

  • The geographical distribution of the validator set;
  • If attesting a non-compliant block may itself be considered a violation in some jurisdictions.

If that's the case, the behavioral pattern you wish to enforce may not come into existence in the end.

One last legal-adjacent point: Suppose I'm a proposer based in some given jurisdiction. Suppose furthermore that there's some non-compliant TX that I know is considered mandated by the majority of validators. What should I do? The way I see it my choice now lies between being non-compliant or minting a block that I know will be de-facto not attested enough. The problem I see here is that I cannot claim that as a proposer 'my hands were tied': I had a choice, and thus I would have had to willingly choose if I wanted to break the law or not.

TL;DR: We should have some law expert to chime in on this.

@mteam88
Copy link

mteam88 commented May 18, 2024

I think you're wrong. This "mandate" would still require adhering to the basefee, and any transaction that does adhere to the basefee would be ordered greedily via their tip. Only the mandates that "fit" into the block according to "economically rational actor" rules would be required to be moved in. This proposal would not "guarantee" you a slot just because you made a cheap transaction, but it would guarantee you a slot if your transaction is legitimately valuable enough to have priority in the next (X blocks).

I think I understand what you're saying a bit better now. I still think this would change the gas fee pricing dynamics, but this may be a reasonable tradeoff.

So 1) yes, it does somewhat impact MEV miners, but b) who are we catering the network for? The proposal does not "kill" MEV extraction at all, and the juicy transaction left on the table remains there and can still be included later, so it's not lost "value" either. Of course and censorship resistance is going to mess with MEV a bit. Don't see it as bad though.

Fair. I am more thinking this will conflict with incentives enough that getting adoption/support from builders will be difficult. If proposers are required to sacrifice EL rewards (assuming block value goes down) then proposer will also be more hesitant to support it.

But yes, it would mean that clients would need to put some effort into making their transaction pools a bit tighter and not yolo it. I think requiring validators to be able to track the best X transactions in the network is not a high ask.

Interesting take. Most proposers now track very few transactions (they outsource this to builders through mev-boost) and therefore this would be a significant requirement increase.

@mteam88
Copy link

mteam88 commented May 18, 2024

@karalabe
Afaict this proposal is completely incompatible with other parts of Ethereum's roadmap (stateless validators comes to mind) and would need to consider blobs aswell. Please correct me if I'm wrong.

@caiosabarros
Copy link

@caiosabarros

A very high-level incentive for such mandates would be to have two set of proposers - the 32 eth stakers and the S eth stakers (S <32) - i.e, the ones that had received a discount for staking - for example, instead of staking 32 eth, they'd be staking S eth (S<32) and then they would be chosen from X to X blocks and the mandated transactions would be sent by them, forcibly. The incentive here would be the discount for them - which could become a broader incentive to everyone else. For those trying to get the most MEV rewards, they'd still be part of the common set of validators, but they'd be willing to put on stake their 32 eth. Rewards are continue to drive behavior in the network, however, we can mkae it easier for those who want to strengthen CR. Also, something of this sort allows more diversity in the network and enhances decentralization.

I have to admit I'm not really following your idea here (unsure what S < 32 stakers are). My gut reaction by the bits I understood is that I don't think making such a mechanism too smart is a good idea. If it's something simple, it's effects can be understood, it's risks can be understood, etc. When you start making it "smart", it also start so become much more easily/sneakily gameable.

Alright, it is much simpler than what it looks like. I tried to be concise in my thoughts, but I left out important information. Let's go to the example of Alice and Bob. Assuming the incentives will always be monetary, we might be able to do the following:

  • Bob is a validator of type I. Bob stakes 32 eth to perform its tasks. Bob proposes blocks having in mind his MEV rewards, not fully committed to CR.
  • Alice is a validator of type II. Alice stakes 20 eth to perform her tasks. Alice received this discount because Alice will always forcibly propose blocks of mandate transactions, where her MEV rewards will be limited due to her commitment to CR.

In summary, there are two kinds of proposers - one that stakes more to have the current capabilities proposers have. The other kind stakes less than the current requirements, while sacrificing the MEV rewards while maintaining the CR in the network.

The discounted amount used as an example here was 20 ETH (for Alice), but I referred to it as S in my previous comment.

The idea is to have the mandate transactions executed by some proposer who got a discount while staking (incentive). The periodicity of such mandate blocks could be fixed (like from X to X blocks, 1 mandate block).

@bertmiller
Copy link

One thing about this that makes me a bit uncomfortable is that it more directly ties network stability to mempool stability. I imagine this introduces a bunch of new attacks, e.g. trying to make sure one part of the network sees a tx and the other doesn't.

As others have said above, the prio-fee ordering requirement also has consequences for MEV - it'll lead to less profitable blocks and a bunch of new games.

@potuz
Copy link

potuz commented May 20, 2024

One concern I have is that validators cannot know statically after 3074 or any variation of AA, if their local mempool transactions are includable in a block. That is, they may have two transactions that are perfectly includable individually but that aren't jointly includable (for example if one tx drains balance of the second one's sender). This is even possible today for the same sender (although this case can be dealt statically by just requiring at least one tx per sender to be included).

This means that validators will need to have extra runtime computation not only for block validation but now for forkchoice decision.

Notice that it was this very same problem that led our only current "solution" to censor resistance, EIP 7547, to be delayed. I am hopeful that we will include it in the following fork either when we include Peer-DAS or ePBS that are likely to include the forkchoice changes necessary to attenuate the problems of inclusion lists

@AndreaLanfranchi
Copy link

I second @bertmiller concerns. Mempool propagation relies not only on incentivized nodes but also on peers that do not partecipate in the formation of the consensus (only verify it) and actually relay TXes for free. These nodes, granted a higher level of anonimity, play a crucial role in possible network segmentation or delayed re-transmission of censorship targeted TXes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment