Execution Tickets

[mikeneuder]

hi terence thanks for the comment.

@terence

• The analysis of the economics of MEV becomes more complex when shifting to this model. Currently, the highest bidder wins, but in this new model, the winner is determined by a randomly chosen lottery ticket, moving from a first-price auction to a more complex format. Is there any analysis using mainnet data from the past six months to retrospectively examine outcomes under this new auction model?

i am not sure i agree that the economics are more complicated. if anything the validator economics are simplified by this model, because they no longer are earning MEV rewards for producing blocks. the MEV boost auction could and probably would still exist as a first price auction for the JIT block production, but now the seller is the ticket holder rather than the validator. so while i agree there are probably two (and maybe more) sellings of the blockspace, i don’t see the last auction that ends up selling to the builder as any more complex.

@terence

• In the previous ePBS design, which Potuz, EPF, and I worked on, builders were staked. This approach faced resistance due to capital inefficiency and a need for compelling reasons. Is it reasonable to consider the purchase of an execution ticket as a form of staking? I will attempt to outline the differences. The introduction of execution tickets expands the design space, balancing research and implementation complexities.

some really nice points. i for sure agree that this is closer to the “builder staking” model than any other design we have come to. my issue with staked builders has always been that there is no attributable slashing condition for their stake. for sure we can punish them for missing slots, but i don’t believe we can socially slash for bypassing the protocol (e.g., by using a relay). as far as local building, i agree. i don’t think local building would be profitable under this model. playing the block lottery could be though! for example, i could buy a ticket in the hopes of getting a high value slot and selling it into the mev-boost auction. if the ticket pricing mechanism charges about the average block reward, this might be 0 EV behavior but with a fun skewed distribution that might result in a big random lottery win

@terence

From an implementation perspective, it’s uncertain whether client teams will be responsible for developing the new “execution proposer” software. If not, this could be advantageous in reducing the codebase. However, it’s important to note that creating the execution proposer software will be challenging, especially if slashing conditions are applied. The lookahead aspect is also complex, as it involves caching elements requiring careful analysis.

i don’t think the expectation would be the client teams writing the exec proposer software in the same way that client teams don’t write the builder codebases of today! anyone who is serious about extracting MEV will need custom code with proprietary alpha in order to be profitable. the only thing the clients will need to implement is that verification of the execution proposer block. but it seems like it will be super similar to the beacon block flow of today. of course, when/if the design becomes more well specified, id love to hear if there are particular challenges faced by the client teams.

@terence

I believe the execution attester role should be integrated into the consensus duties, utilizing the current committee structure. For instance, the first index of the committee could perform the execution of attesting duty. Limiting the number of committee members is preferable to avoid an additional aggregation round, thereby saving approximately 4 seconds at the second slot time. An ideal network size would be around 512. This concept necessitates further thought and analysis, particularly regarding the networking aspects.

the execution attesting needs to have similar guarantees from a fork choice perspective as the beacon attesting. this is because of the unbundling style attack outlined in Payload-timeliness committee (PTC) – an ePBS design. for sure more design needed though!

@terence

The beacon block proposer for the subsequent slot will incorporate the execution attestations from the previous slot into their beacon block. The method for determining rewards and penalties for this action still requires analysis.

agreed!