aprioriAgency & MEV-Boost++
What is Agency?Agency is the freedom to act (Voltaire’s definition of liberty).Problems Statement“ How do we bring back the status quo of proof of work style CR where the validators have agency on choosing only builders that are not censoring while maintaining the revenue they can see from MEV optimization. We don’t want validators to choose MEV optimization or censoring. We want them to be at w/e point on that tradeoff point they want to be at. And we want to incubate as many points on this ...
aprioriSearching For The Holy Grail: Order Flow Auctions & The Enshrined Builder
IntroductionUpon reflection, my favorite presentations from the MEV workshop at SBC were Vitalik’s distributed builder, which I reference several times in this article, and @0xQuintus warning about the rise of exclusive order flow. The former put forth several new possible iterations that enhance PBS, while the later articulated the negative externalities of exclusive order flow. Both presentations served as an inspiration for this article. In addition this should also be considered a follow ...
aprioriRandom half-baked thoughts on MEV redistribution
Bootstrapping an EcosystemAs time progresses rollups will look more like public goods than they do today. The question of long-term economic sustainability is contingent on the demand for blockspace. Rollups can contribute to this by funding public goods and using governance as a tool to distribute ecosystem funding. Users and developers will want to go where the action and attention is. We have seen this play out in the last economic cycle with the persistence of the bridge, farm & dump rout...
I write about protocol design, intents & MEV related stuff.
aprioriAgency & MEV-Boost++
What is Agency?Agency is the freedom to act (Voltaire’s definition of liberty).Problems Statement“ How do we bring back the status quo of proof of work style CR where the validators have agency on choosing only builders that are not censoring while maintaining the revenue they can see from MEV optimization. We don’t want validators to choose MEV optimization or censoring. We want them to be at w/e point on that tradeoff point they want to be at. And we want to incubate as many points on this ...
aprioriSearching For The Holy Grail: Order Flow Auctions & The Enshrined Builder
IntroductionUpon reflection, my favorite presentations from the MEV workshop at SBC were Vitalik’s distributed builder, which I reference several times in this article, and @0xQuintus warning about the rise of exclusive order flow. The former put forth several new possible iterations that enhance PBS, while the later articulated the negative externalities of exclusive order flow. Both presentations served as an inspiration for this article. In addition this should also be considered a follow ...
aprioriRandom half-baked thoughts on MEV redistribution
Bootstrapping an EcosystemAs time progresses rollups will look more like public goods than they do today. The question of long-term economic sustainability is contingent on the demand for blockspace. Rollups can contribute to this by funding public goods and using governance as a tool to distribute ecosystem funding. Users and developers will want to go where the action and attention is. We have seen this play out in the last economic cycle with the persistence of the bridge, farm & dump rout...
I write about protocol design, intents & MEV related stuff.
Subscribe to apriori
Subscribe to apriori
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
The inspiration for this post came after spending too much time reading the bird app, capped off by this post here.
There are many opinions about what the Ethereum community should do to combat transaction censorship from block builders and relays. From what I’ve gathered, social consensus amongst community members appears to favor enshrining crLists ASAP.
One of the best decisions Ethereum developers made was pivoting away from execution sharding to a rollup centric roadmap. To quote Hasu, “Ethereum has effectively deregulated its execution market.” This deregulation has fostered permissionless innovation allowing rollups to move faster and make tradeoffs that Ethereum cannot make (upgrade keys, exit games, proof generation, single sequencer, et al.). More examples of permissionless innovation likely to be implemented in protocol include;
MEV-Boost-> PBS
Zk Rollups -> zkEVM
Eigen DA -> danksharding
Lido -> in protocol LSD
Furthermore, I propose an alternative to enshrined crLists that retains credible neutrality while requiring no (minimal?) changes to consensus or execution clients. Instead I’m proposing an update to Mev-Boost.
How do we solve the problem of getting transactions included in a block that some builder/relay entities will not include like transactions from OFAC sanctioned addresses and contracts for example?
At the moment, it appears unlikely that a crList EIP will to be appended to the current CFI (considered for inclusion) list in time for the Shanghai Hard fork. However, we do not need to rush an in protocol upgrade for the sake of saying we satisfied our current censorship problem.
A simple but elegant solution could be to add a patch to Mev-Boost that allows the consensus client to connect to a new type of Builder API that runs in parallel with the existing Builder API and would allow each client to connect to a crList builder/relay.
The crList builder would receive a transaction inclusion list from the last proposer to be included in the next slot. If the block is not full and the pending tx fees >= the base fee then the crList builder would aggregate the crList txs and relay the txs to the proposer. If the builder’s block is full, 2x the target, then the crList builder would not relay the aggregated txs to the proposer. Otherwise the crList builder would always send txs up to the max gas limit of the total block. Indeed, The crList builder is only constructing a small fraction of the block.
At this point the decision to censor would be entirely up to the Proposer who could choose not to connect to the crList builder/relay.
As an alternative, the crList builder could produce the Inclusion list instead of the proposer. This would likely require some type of opt in slashing conditions to keep to crList builder honest.
Both designs would require altruism by honest actor(s) with the requisite resources to run crList builders and relays.
For better ideas, see Vitalik’s latest proposal.
The current equilibrium between the Ethereum protocol, users/developers, regulators and apps/middlewear suggests that rushing to enshrine crLists could shift the balance and draw further regulatory hostility provoking n+1 countermeasures.
Instead, we should consider implementing crLists (in protocol) during the early phase of the next economic cycle, acting from a position of strength.
Finally, as MEV-Boost allows us to collect empirical data and build deeper intuitions about PBS, an intermediate crList builder update to MEV-Boost will help us make better informed decisions about crLists.
As a community let’s stop using the term crLists. Transaction Inclusion list is okay, but again, we can do better.
crlList → litList (Last included transactions)
Not only is this a better meme than crList, It’s lit. The power of memes should not be overlooked. Though I do like Inclusion List as well.
Testing crLists with MEV-Boost could be more beneficial than playing the reactionary meta-game with unknown outcomes
litList (crList) builder can send a prefix or suffix to proposer to be added to the execution block , but requires at least 1 altruistic actor(s) to run a Builder/relay combination (roles can be split, multiple altruists)
In protocol crList should ship only when ready
litList is a better meme, (FitList for prefix) but Inclusion List is strong as well
The inspiration for this post came after spending too much time reading the bird app, capped off by this post here.
There are many opinions about what the Ethereum community should do to combat transaction censorship from block builders and relays. From what I’ve gathered, social consensus amongst community members appears to favor enshrining crLists ASAP.
One of the best decisions Ethereum developers made was pivoting away from execution sharding to a rollup centric roadmap. To quote Hasu, “Ethereum has effectively deregulated its execution market.” This deregulation has fostered permissionless innovation allowing rollups to move faster and make tradeoffs that Ethereum cannot make (upgrade keys, exit games, proof generation, single sequencer, et al.). More examples of permissionless innovation likely to be implemented in protocol include;
MEV-Boost-> PBS
Zk Rollups -> zkEVM
Eigen DA -> danksharding
Lido -> in protocol LSD
Furthermore, I propose an alternative to enshrined crLists that retains credible neutrality while requiring no (minimal?) changes to consensus or execution clients. Instead I’m proposing an update to Mev-Boost.
How do we solve the problem of getting transactions included in a block that some builder/relay entities will not include like transactions from OFAC sanctioned addresses and contracts for example?
At the moment, it appears unlikely that a crList EIP will to be appended to the current CFI (considered for inclusion) list in time for the Shanghai Hard fork. However, we do not need to rush an in protocol upgrade for the sake of saying we satisfied our current censorship problem.
A simple but elegant solution could be to add a patch to Mev-Boost that allows the consensus client to connect to a new type of Builder API that runs in parallel with the existing Builder API and would allow each client to connect to a crList builder/relay.
The crList builder would receive a transaction inclusion list from the last proposer to be included in the next slot. If the block is not full and the pending tx fees >= the base fee then the crList builder would aggregate the crList txs and relay the txs to the proposer. If the builder’s block is full, 2x the target, then the crList builder would not relay the aggregated txs to the proposer. Otherwise the crList builder would always send txs up to the max gas limit of the total block. Indeed, The crList builder is only constructing a small fraction of the block.
At this point the decision to censor would be entirely up to the Proposer who could choose not to connect to the crList builder/relay.
As an alternative, the crList builder could produce the Inclusion list instead of the proposer. This would likely require some type of opt in slashing conditions to keep to crList builder honest.
Both designs would require altruism by honest actor(s) with the requisite resources to run crList builders and relays.
For better ideas, see Vitalik’s latest proposal.
The current equilibrium between the Ethereum protocol, users/developers, regulators and apps/middlewear suggests that rushing to enshrine crLists could shift the balance and draw further regulatory hostility provoking n+1 countermeasures.
Instead, we should consider implementing crLists (in protocol) during the early phase of the next economic cycle, acting from a position of strength.
Finally, as MEV-Boost allows us to collect empirical data and build deeper intuitions about PBS, an intermediate crList builder update to MEV-Boost will help us make better informed decisions about crLists.
As a community let’s stop using the term crLists. Transaction Inclusion list is okay, but again, we can do better.
crlList → litList (Last included transactions)
Not only is this a better meme than crList, It’s lit. The power of memes should not be overlooked. Though I do like Inclusion List as well.
Testing crLists with MEV-Boost could be more beneficial than playing the reactionary meta-game with unknown outcomes
litList (crList) builder can send a prefix or suffix to proposer to be added to the execution block , but requires at least 1 altruistic actor(s) to run a Builder/relay combination (roles can be split, multiple altruists)
In protocol crList should ship only when ready
litList is a better meme, (FitList for prefix) but Inclusion List is strong as well
No activity yet