Tl;dr: we can abstract execution tickets even further by expecting something more general than a signature. This could smoothly allow PEPC, distributed-block-builders and other weird things.
proposed a concrete mechanism that takes the “PBS” separation to its natural conclusion
formed the concept of “proposing rights” and made it clear that this is something which can be allocated in arbitrary ways.
In particular, the execution ticket proposal has gotten people to discuss the allocation of proposal rights more generally. The questions (which we are slowly working on answering) that came up along these lines are:
what properties do/can we want from the proposing right market in terms of concentration, contestability, geo distribution etc?
how far in advance should proposing rights be allocated?
to whom should rights be allocated? Randomly to stakers? To whomever buys it?
etc.
However, I think we haven’t really gone the full way of generalising what an execution ticket is. A reasonable model for capturing the popular understanding of execution tickets is a data structure with three fields. Here I am using an execution ticket as a means to represent proposing rights, not necessarily within the context of the lottery that was originally proposed:
owning_account - this eth account has the ability to change proposing and owning ticket fields (i.e. change the owner and proposing key).
slot_no - at some point the protocol sets this value according to some unspecified rule, likely with only one ticket per slot (but who knows)
proposing_key - when the current slot is equal slot_no, the chain accepts as valid only blocks that are signed by the proposing key
as we have today, the protocol probably specifies some slashing conditions according to which funds associated with a ticket are subject slashing. For instance, this would prevent one ticket being used to produce two valid blocks (equivocating).
The core point I want to make is that we can generalise the proposing key to just be a proposing check. Instead of validators expecting a signature from a specific key, they could expect some input which, when fed into to the proposing_check script, evaluates to true.
The only constraint on the proposing script is that it shouldn’t be too expensive to execute to prevent validators from being DoS’ed. We could take a hint from the work on SNARK accounts on Celestia and verify proofs using this field. I suspect there’s a lot of wild stuff we can do here that I haven’t thought of, but two interesting directions:
constrain block validity: Especially if there was a way to lock the proposing_check so that it couldn’t be changed, this would be a way to commit the block to conforming to a broad class of rules (similar to what was suggested in PEPC) in addition to the protocol’s block validity rules. This includes inclusion lists or certain ordering rules.
light clients: For example, you could require that an L1 block is actually a concatenation of many smaller blocks from a different chain. This is interesting for decentralised block building, but probably for some other things.
Both of these framings can probably lead to some really interesting constructions. I haven’t thought about this very deeply yet so I assume there are other interesting directions to take this as well.
Outside of the constructions we would practically want to build, it is also just an interesting reframing of execution tickets (at least to me). One interesting intersection to explore here is the overlap between this idea and “the ethereum as a rollup to itself” framing. My aspiration with this post is to stimulate another philosophical tractus from @barnabemonnot.
APS-Burn is akin to an “execution auction”, where the MEV-Burn auction allocates the proposing right for a slot 32 slots in advance. PEPC is additive to this construction: We may further allow the execution proposer to register proposer commitments with respect to the block that they will propose (which may be built by builder(s)).
As I understand it, APS-Burn + PEPC would essentially allow an execution proposer to set proposing_check such that they would be unable to propose a block which does not satisfy the commitment script.
It was not written in the post but I believe the proposing_check could be built up in several non-conflicting ways:
The would-be execution proposer who participates in the APS-Burn execution auction could pass proposing_check along with their bid data. If their bid is selected as the winning bid, the proposing_check is then set somewhere in, e.g., the beacon state for validators to execute when they receive the block proposed by the winning execution proposer.
In-between the execution auction (at slot N) and either the beacon block at slot N+32 or the execution block at slot N+31, the winning execution proposer for slot N+32 could register additional commitments if such a facility existed (e.g., either as a beacon block-includable transaction or as an execution block-includable transaction). The additional commitments would “overload” proposing_check, adding additional commitments to satisfy (it’s interesting whether we want to allow the execution proposer to also be able to remove commitments, I guess probably not?)
If we did not care for the ability for the execution proposer to register “just-in-time” commitments during the execution proposing step at slot N+32, we could stop here. But I think it would be valuable for an execution proposer to do that, so that they could register, e.g., commitments they entered into between the proposing of the beacon block at slot N+32 and their own step of proposing the execution block. Additionally, if the execution proposer was censored and prevented from registering commitments anytime between slot N and the beacon step at N+32, they would now have a block they fully control and so could include themselves here. This however imposes layering ePBS (classic PEPC in this case really) on top of APS-Burn, giving us the three-step construction depicted above.
Does this align with some of the designs you had in mind?
Cool idea! I think one fundamental question we still have to ask is whether the protocol allows reselling tickets. Reselling tickets opens up complexity and even attack vectors that I worry about. But I think this post is independent of reselling tickets; rather, it’s about the ticket owner selling its additional commitments. One intuitive question I have is whether there are any concerns about allowing proposers to keep selling additional commitments without removing the old ones. Could there be a real-world example where a seller sells commitment A to a buyer for price X and then a few slots later sells commitment B for price Y, but the first buyer wouldn’t have paid X if they had known B was going to be sold? This devalues X. Maybe it’s not a concern as long as the commitments are executed in order. Will think more on what’s a good example of this…
I consider APS-burn a form of allocation ticket and thus orthogonal to what I’m suggesting. I have started to think of execution tickets as simply the representation of a future proposing right (or a probabilistic one at least), which is an idea that fits with all the allocation mechanisms that aren’t opinionated about the payload is like MEV-Boost.
Yes this is how I have it as well.
I think we should give them an option to commit to a proposing check, but also make it possible to keep things mutable if that makes sense. Having the programmable check is useful for commitments, but I don’t know if that’s the only use case. For instance, if a ticket is sold, the new owner may want to set a check for a signature from their own pubkey (or anything else really). The original owner may set a default check just in case they weren’t able to transfer the ticket or set it later etc.
I think there’s a tradeoff between protocol complexity/secuirty and economic expressiveness here. It might make sense for the protocol to lock tickets in place a few slots before the target slot and even if they didn’t there would still be a slot’s time in which no commitments could be made.
One solution, I’ve had at the back of my mind is using TEEs to facilitate the last moment commitments. Either by the ticket holder showing a proof that they generated a proposing key in a TEE or by the chain checking a TEE attestation in the proposing_check
