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.
Share Dialog
Share Dialog
Subscribe to apriori
Subscribe to apriori
One of the fundamental problems of Proposer Builder separation is the centralized role played by the Builder. This creates 3 tradeoffs (possibly more):
Regulatory choke-point
Builder consolidation
Vertical integration of supply chain
Proposal
Can we conceive of a decentralized block builder?
Conjecture: considering Near’s Nightshade design, loosely, for inspiration we can conceive of a decentralized builder design where multiple builders compete to propose a chunk or a portion of the execution block.
Inspiration - Near Nightshade (2019 White Paper)
Design
In this proposal there would be four distinct auctions, 3 competitive and 1 non-competitive. The Auctions could be run sequentially, metered by time. For instance auction n lasts x seconds. The MEV competitive auctions include both bundles and mega bundles. The target gas limit of these three auctions in total is 15M gas, 5M each. The fourth auction is the censorship resistance list. The crList target gas is 0M gas. The MEV competitive auctions have a max gas limit of 10M each. If all three auctions reached the 10M gas limit, the crList auction would not submit a bid chunk and begin again the following block.
The Sharded Builder - Hypothetical Ethereum with PBS
Builders can only compete in 1 MEV competitive auction per execution block
1 auction is exclusively for Mega bundles capped by auction gas limit
Proposer selects highest chunk bid for each auction.
Winning chunk headers are aggregated by proposer to create singular block header
Sequential auctions mitigate risk of overlapping txs or requiring state access lists
Conclusion
The proposed sharded block builder design creates a highly decentralized and competitive builder market. In addition, builder competition ensures exclusive order flow does not lock into a handful of centralized builders. This is because of the proposed limitation on the number of auctions a single builder can compete in per block. Time based auctions keep top of the block opportunities competitive and reduce the risk of builders holding blocks until more order flow is revealed. crList chunks have the opportunity to be included in every block. Exclusion occurs only if the MEV competitive auctions reach their max gas limits respectively.
Open Questions
New DOS attack vectors?
Can proposal be implemented as middle-wear or does it require both execution and consensus client upgrades?
How will this affect Danksharding? If full Danksharding is not possible with a sharded builder, does the community pivot to PDS (EIP 4844) then done?
How will this affect stateless client implementation? Will chunks require additional witness data to verify?
Is additional validator overhead (chunk header aggregation) cost neutral?
Compatible with single slot PBS or two slot PBS?
One of the fundamental problems of Proposer Builder separation is the centralized role played by the Builder. This creates 3 tradeoffs (possibly more):
Regulatory choke-point
Builder consolidation
Vertical integration of supply chain
Proposal
Can we conceive of a decentralized block builder?
Conjecture: considering Near’s Nightshade design, loosely, for inspiration we can conceive of a decentralized builder design where multiple builders compete to propose a chunk or a portion of the execution block.
Inspiration - Near Nightshade (2019 White Paper)
Design
In this proposal there would be four distinct auctions, 3 competitive and 1 non-competitive. The Auctions could be run sequentially, metered by time. For instance auction n lasts x seconds. The MEV competitive auctions include both bundles and mega bundles. The target gas limit of these three auctions in total is 15M gas, 5M each. The fourth auction is the censorship resistance list. The crList target gas is 0M gas. The MEV competitive auctions have a max gas limit of 10M each. If all three auctions reached the 10M gas limit, the crList auction would not submit a bid chunk and begin again the following block.
The Sharded Builder - Hypothetical Ethereum with PBS
Builders can only compete in 1 MEV competitive auction per execution block
1 auction is exclusively for Mega bundles capped by auction gas limit
Proposer selects highest chunk bid for each auction.
Winning chunk headers are aggregated by proposer to create singular block header
Sequential auctions mitigate risk of overlapping txs or requiring state access lists
Conclusion
The proposed sharded block builder design creates a highly decentralized and competitive builder market. In addition, builder competition ensures exclusive order flow does not lock into a handful of centralized builders. This is because of the proposed limitation on the number of auctions a single builder can compete in per block. Time based auctions keep top of the block opportunities competitive and reduce the risk of builders holding blocks until more order flow is revealed. crList chunks have the opportunity to be included in every block. Exclusion occurs only if the MEV competitive auctions reach their max gas limits respectively.
Open Questions
New DOS attack vectors?
Can proposal be implemented as middle-wear or does it require both execution and consensus client upgrades?
How will this affect Danksharding? If full Danksharding is not possible with a sharded builder, does the community pivot to PDS (EIP 4844) then done?
How will this affect stateless client implementation? Will chunks require additional witness data to verify?
Is additional validator overhead (chunk header aggregation) cost neutral?
Compatible with single slot PBS or two slot PBS?
<100 subscribers
<100 subscribers
No activity yet