18559
terence
@terencechain #18559
Ethereum
https://terencecha.in/
167041 Follower 53 Following
Wrote a post on FOCIL resource considerations after reflecting on how clients might implement it. We outlined some concerns about potential bottlenecks, hoping to spark more discussions to move it toward the spec realization phase. Feedback welcome! https://ethresear.ch/t/focil-resource-design-considerations/20457
ePBS breakout #8 notes: https://hackmd.io/@ttsao/epbs-breakout-8
Moving to slot auctions seems imminent at this point, the question is when. If we want to have slot auctions for the very first client devnet, then the sooner the better
Moving to slot auctions seems imminent at this point, the question is when. If we want to have slot auctions for the very first client devnet, then the sooner the better
Any farcaster fantasy football league this year?
FOCIL vs BRAID
EIP-7732(ePBS) breakout call #6 notes: https://hackmd.io/@ttsao/epbs-breakout6
New post on inclusion list timing constraints: Different designs bring different timing limitations for inclusion list actors. We argue there's no perfect design due to trade-offs within an Ethereum slot. Feedback welcome.
https://ethresear.ch/t/inclusion-list-timing-constraints/20198
https://ethresear.ch/t/inclusion-list-timing-constraints/20198
New post on builder bidding behaviors in ePBS, inspired by "Strategic Bidding Wars in On-chain Auctions".
In the post we explore market changes from MEV-Boost to bid p2p and builder RPC, and discover a new single bluff strategy on p2p. Special thanks to @soispoke for the review!
🔗 https://ethresear.ch/t/builder-bidding-behaviors-in-epbs/20129
🔗 https://arxiv.org/abs/2312.14510
In the post we explore market changes from MEV-Boost to bid p2p and builder RPC, and discover a new single bluff strategy on p2p. Special thanks to @soispoke for the review!
🔗 https://ethresear.ch/t/builder-bidding-behaviors-in-epbs/20129
🔗 https://arxiv.org/abs/2312.14510
Here are my slides for ethcc on redefining trust between proposer and builder through ePBS. Today, to use a builder, a proposer MUST trust a relayer, which carries invisible costs across multiple domains: money, latency, fault, schedule, and healthy market dynamics. I argue that these costs become cheaper (or go away) with ePBS. Enjoy! https://docs.google.com/presentation/d/1Jw0EZvkZzzeKWi-yehwLWdIl4VEZ1Le9_ywDrFDS6Oc/edit?usp=sharing
Here are the slides during ethcc on pipelining ethereum consensus & execution. While many discuss pbs for trust, censorship, and latency, few highlight its benefits for better slot utilization, more execution time & DA time. https://docs.google.com/presentation/d/1Il19qu0b7gr7GBUCNkr-aRh8lqxmBX5OSqfv5mVtTAA/edit?usp=sharing
epbs breakout #4 call notes, check the highlighted section for a quick TLDR: https://hackmd.io/@ttsao/epbs-breakout4
EIP7732 is live! 🎉 The first EIP on ePBS and separating proposer and builder roles. This EIP focuses on block auctions, but future work could extend to slot or ticket auctions. Feel free to take a look and ask any questions.
https://eips.ethereum.org/EIPS/eip-7732
https://eips.ethereum.org/EIPS/eip-7732
New post on fork choice attacks in EPBS: https://ethresear.ch/t/fork-choice-attacks-and-protections-in-epbs/19951 .I covered existing write-ups on EPBS post-anti, ex-anti, and new builder reorg and withholding attacks, including the new boost values and why some attacks are more useful than others. Feedback welcome.
Timeboost is a new transaction ordering design/policy we have been studying for a while. It resembles an execution auction where the winner gains fast lane access instead of re-ordering right. I'm curious to hear anyone's feedback.
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167
Curious to hear what's the downside of this strawman idea to make the current blob market more efficient:
- 90% of blocks are built by the builder
- Rollups submit blobs directly to the builder's blob mempool or something like Flashbots RPC
- Builder’s mempool allows white-listed addresses from rollups. Adopt a less strict version of mempool rules:
- Allow white-listed addresses to submit a vector of blob txs with varying blob counts (1-6)
- These vectors can have different tip amounts
- Implement a less restrictive tip replacement rule for these addresses
- Assuming a few rollups opt-in, the builder can mix and match blob txs from different rollups more efficiently than before, improving market clearing...
- 90% of blocks are built by the builder
- Rollups submit blobs directly to the builder's blob mempool or something like Flashbots RPC
- Builder’s mempool allows white-listed addresses from rollups. Adopt a less strict version of mempool rules:
- Allow white-listed addresses to submit a vector of blob txs with varying blob counts (1-6)
- These vectors can have different tip amounts
- Implement a less restrictive tip replacement rule for these addresses
- Assuming a few rollups opt-in, the builder can mix and match blob txs from different rollups more efficiently than before, improving market clearing...
3.) I think we can solve the blob market with the above, but there may still be times that builders refuse to accept blob txs. Builders don't run default client software. One solution to fix this is to just tell posters to increase the tip until builders include it. Another solution is a protocol force inclusion list for blob transactions, which we haven't thought much about.
Excited to see how this develops!
Excited to see how this develops!
2.) The current blob market is inefficient at matchmaking; it doesn't clear well. Most posters submit their best strategy blob tx. Given the max blob per block is 6, posters may send a tx with 1 to 6 blobs. Posters’ best strategy may change; Alice sent 6 blobs at time t1, then Bob sent 1 blob with a higher tip at t2. The builder picks Bob's tx because of the higher tip. If Alice had known Bob's intent, Alice would have sent 5 blobs at t1 instead of 6. To fix this, we either need a more relaxed version of the mempool that accepts a "menu" of txs and allows mix-matching. A relaxed mempool leads to DoS risk, so it would make sense to be done on the builder side and maybe just accept whitelisted senders to begin with. Another solution is to have a secondary market to mix-match blob txs to maximize social wellfair.
Last smol post on unpacking the current blob market issue as far as what I can see. I can't claim I have a good solution to any of this, but I'm excited to see how it unfolds in the coming months.
1.) Blob tip is not an independent field. It's shared with execution tip. The total tip paid is execution tip multiplied by gas usage. Given two txs, one with higher execution usages than the other, the tip will be higher but that doesn't tell anything about how many blobs there are. Example: {blob_count: 6, tip: 2, gas_used: 5} beats out {blob_count: 1, tip: 9, gas_used: 1} even though it's paying a higher total tip in the end. It's not clear to me who simulates, I was told some builders already simulate, but the cleanest solution is to give the blob tip its own field.
1.) Blob tip is not an independent field. It's shared with execution tip. The total tip paid is execution tip multiplied by gas usage. Given two txs, one with higher execution usages than the other, the tip will be higher but that doesn't tell anything about how many blobs there are. Example: {blob_count: 6, tip: 2, gas_used: 5} beats out {blob_count: 1, tip: 9, gas_used: 1} even though it's paying a higher total tip in the end. It's not clear to me who simulates, I was told some builders already simulate, but the cleanest solution is to give the blob tip its own field.
ePBS breakout call #3 notes: https://hackmd.io/@ttsao/epbs-breakout3