leanConsensus Call #5: Attester-proposer separation

Transcript

Hello and welcome to beam call number five already. Today's topic is APS a tester proposer separation and we're going to have uh Julian run the the call today. Uh but before that I'm just going to give a very very quick presentation to set a little bit of context. Okay. So um already call number five. Uh in two weeks we have call number six. Uh we're going to have two set of presentations. Uh one of them uh by Vitalik who actually uh implemented 3SF in a matter of a few days in in in Python. So he'll be presenting his

stuff. Uh and we also going to have Roberto, Franchesco and Luca also talk about uh the work that they've been doing. Uh and again you know on June 29th we have beam day can and uh there should be a QR code maybe not. Okay QR code is in the the slides from uh from from from last time. So today uh we have uh Julian uh who will who will be uh presenting. Now one kind of master link if you're not already aware of it is APS. directory. Uh I believe this is a a notion doc that is maintained by by

Julian and it has all sorts of other links uh to to continue your exploration of of APS. Now what are we trying to achieve with APS? So in in my opinion, one of the big value propositions of APS is this notion of of Zen staking where we really want the the stakers, the testers, you know, the operators of these these validators to be as uh unsophisticated as as possible. And today without APS, uh there's a few things that the operators have to to worry about. One of the first things that they have to worry about is me. So they have to install an extra piece of

middleware called meth boost. They have to pick some relays uh and there's all sorts of uh of complications there as to which relays you pick depending on whether you're regulated or not regulated and blah blah blah. Um there's also this issue of me spikes. Basically you get uh selected as a proposer at random. This is sort of a lottery and when you do get selected there's kind of the second order rand randomness where uh you sometimes you happen to get really lucky because it's a for example a period of high volatility when there's a lot of me and these spikes are actually unfriendly to uh to decentralization because the uh median validator your typical validator will

make less than your average validator and the reason is that every once in a while someone wins a very very big jackpot. uh and that will skew the distribution. It will move the average up but you know your your median typical validator will not get access to to to that jackpot and so that incentivizes the creation of of smoothing pools uh which you know adds extra centralization and complexity. Another issue related to meth boost is this notion of timing games. If you are a maximally rational uh operator, you're going to want to play timing games. And uh that adds to the sophistication of of being a validator. And then a final thing

related to me is that sometimes you receive a bunch of me, but it's kind of uh me that maybe you didn't want to receive. So for example, it could be the proceed of a hack um or it could be the proceeds of sandwiching or something like that. and and and here there's there's a bit of a of a moral dilemma like should you return the funds or not and that's that's something that uh I believe the the validator should should not be exposed to and then there's a kind of a whole second class of things that the validators potentially have to worry about uh in the in the notsodistant future which is related to this notion of proposer commitments. So there's a piece of software called

commit boost um that uh allows proposers to opt in to to commitments. One of which is is preconfirmations. Um but if you have preconfirmations, you probably also have uh the equivalent of relays which is the the gateways and also you have if you want to uh play the pre-confirmation game, you need to add collateral. And so all of these things basically add complexity that uh to the to the validators that we we we we want to um remove. And basically the idea here is called a tester proposer separation where all of the sophistication falls on the proposer which is a separate entity uh one which

is assumed to be sophisticated and can play all of those games. uh and the testers can just be super dumb uh entities that that run on on on Raspberry Pies or on on smartwatches. Now, um if if we zoom out to all of the uh consensus layer improvements, this is a slide that I had in my in my Defvcon talk. In my opinion, uh the least drisk is actually uh a test of proposal separation and the reason is that there isn't really a clear answer as to what we should do. I think what we we've done so far is that we've explored the design

space. Um but we uh we don't know and you know we have multiple uh possible candidates but we don't know which candidate to pick and the reason is that there are some fundamental trade-offs that that have to be made. But if we look at uh you know trying to give a score in terms of d-risking I'd give issuance and randomness a five out of five. And the reason is that uh these would not uh be part of the of the beam chain. Uh smarter issuance would either be done pre-beam or post beam. Uh and uh VDF randomness would would be done after the the beam fork.

Um, you know, these numbers are subjective, but in my opinion, we're making fantastic progress in d-risking fossil, uh, which, um, may come in Amsterdam. We already have an EIP for it. Uh, I think 3SF is also very much derisked. And Poseidon 2 and and and in general, um, snarkification of the whole chain, I think, is very very much derisked. And if you're interested in keeping track with all of the progress on ZKVMs, we have a separate call if proofs uh call which you're welcome to join. And one of the reasons why I'm relatively, you know, happy with percent 2 is because even if there is some sort of a a small attack on pose 2, there is

an easy way to defend against it, which is just to add more internal rounds to the hash function to to boost uh boost the the security. And then there's a few things here uh which I'd give a three out of five in terms of uh d-risking which are things that you know we're still investigating. They're somewhat new. They've never been done before. Uh so you know quantum signatures have never been done before. Uh rainbow staking and uh and smaller slots have have never been done in the context of Ethereum.

And but you know overall I'm I'm not too worried. Um and you know this brings us to the the final point which is a test of proposal separation. I think this is the one topic that has the the lowest score from a t- risking perspective and the fact that we're talking about it today uh hopefully is a forcing function to uh to make progress here. So again uh today's speaker is uh Julian research at different foundation and I'll I'll share the the floor with him. Julian you may take it from here.

Awesome. Let me share my [Music] screen. Can you see my screen? Yep. Perfect. Okay. Well, first of all, thanks for the the great context setting for APS. Um, yeah. So, I would say APS to me feels like we're firewalling testers and proposers uh very much. And as Justin said, uh there doesn't seem to be one um silver bullet solution. So what today I'll be presenting is some background information of why we want it uh and how we've thought about achieving it. Uh then go into a specific proposal that maybe threads the needle quite well between all of the different things that we want from APS. Um and lastly explain if we don't if we don't go for this

silver bulletish solution that relies on uh some heavy assumptions how can we um relieve some of these assumptions and what does that mean for uh what we get out of the mechanism. So the goal is really to uh help people understand the design space uh see what we have done so far uh and show what decisions basically have to be made uh and finally how we can make those decisions. Okay. Okay. So, I'll try to go through the background fairly fast because probably lots of people here are familiar. Um, and yeah, I I don't want to lose people um throughout. However, also feel free to ask questions during the presentation uh as it's nice to just keep up with the presentation and probably other people will be wondering about the same

things. So, I'm going to start with a quick recap of how we select proposers today. Suppose there is the blockchain and Alice has built block 99. Bob has built block 100 and then we need to select who builds block 101. Today Ethereum does so by randomly selecting a validator from the validator set who then becomes the proposer of the block. And I put this asterisk on the die because actually we don't randomly select a validator within block 101 to become the validator of block 101. But we do so up to two epochs in advance uh because of the limitations of the randomness that we have in Ethereum today.

Um then this randomly selected validator uh mostly chooses a builder via meth boost as most of you will be familiar and so this builder pays the validator something for the right to construct a block and the validator gives the builder its execution proposing rights and APS is fundamentally about changing the way that we select proposers here. So instead of doing this indirect method where Ethereum uh sets randomly picks a validator via via randow and this random validator then probably um sells its execution proposing rights to the builder. APS aims to achieve that the Ethereum protocol itself can choose a builder directly. So that's what the direct link here signifies. And

so why would we actually want APS? Well, um, Justin actually introduced APS in the end of 2023 as a method to combat proposal timing gains. And timing gains refers to the economic benefits a proposer can get by proposing a block after the owner's proposal deadline. Uh, and therefore that proposer can include maybe more transactions or it can better extract me. And so intuitively, it's just you're extending the slot duration and so you're getting some more me out of that. uh and it's bad for the network uh because of this um this effect of geographic centralization. Um so if you are a proposer who's close to other proposers, you can extend your block very late uh because your block will

reach the other proposers very quickly. So let's say that you're in the US and there are lots of other US-based proposers around you. Uh they'll receive your block very quickly and they'll vote for your block and it will probably still become canonical. Let's say now that you're a proposer on Antarctica or something uh then there will be very few proposers around you. So you have to account for the time that it takes for your data to be transmitted over the network and reach the other testers and that they'll actually vote for you. Um so timing games have this geographic centralization incentive which is the which was at least the the main motivation to get rid of it and go for a tester proposer separation. Justin initially proposed execution tickets which works uh roughly

as follows. The Ethereum protocol sets up an execution ticket market and this market can look uh in a like a variety of things but the main idea that it looks like is people buy their ticket where tickets have a fixed price and the supply is flexible and they do so quite far in advance. So, for example, 32 slots in advance, and this removes any of the timing games incentives. Uh, because 32 slots in advance, it's unlikely that there's any new information coming in this this extra tiny bit of time that you have to play timing games. So, the execution proposers who are similar to the builders today, uh, they buy their tickets in these markets far in advance, uh, and their proceeds of of this markets are burned. And then

uh when it comes closer to the time of proposing uh one of these execution proposers is randomly picked uh and the probability of winning is proportional to the amount of money they spent on tickets. So assume that there are two execution proposers who want to win the the markets. One has bought 10 tickets and the other has bought 20. Then the person that bought 20 tickets has a 2/3 probability of winning and the person that bought 10 has a 1/3 probability of winning. But they both pay for those tickets and they won't get any refund if they if they don't um become the the actual winner of the market. Uh and separately uh the Ethereum proposal appoints a beacon proposer and the beacon proposer is in charge of making a beacon block um which we won't go too much into but for context it means it's

it's a block that contains attestations and cons consensus information uh that's important to progress the chain. Then another proposal for APS has been execution options which is proposed by Barnab and it's maybe a simpler design that looks more like me today. Uh the Ethereum protocol would use one of the beacon proposers. So the beacon proposer slot N to sell the execution proposing rights of slot N plus 32. And we use this 32 slot difference again uh to prevent any timing games. And uh this up until now it looks very similar to met me met me met me met me met me met me met me met me met me met me met boo boo boo boo boo boo boo boo boo boo boo boost uh but the difference is that the ethereum protocol forces the beacon proposer um to pick the highest bid and that's signified here by this little

burning emoji which uh represents meburn and so mebburn is a tool that allows Ethereum to force someone to pick the highest bid and then the the auction proceeds are burnt so is that if if that's clear for everyone I'll continue but if there are questions feel free to asked. Yeah, feel free to raise your hand at any time. Perfect. I'll just continue, but if there are questions, feel free to ask throughout the the presentation. Okay, so execution tickets and execution auctions have been proposed quite a while ago now. Uh execution tickets at the end of 2023 and execution auctions at the beginning of 2024. And so why has taken us some time to further uh APS is because of two main critiques. One of

them is centralization and the other one is multis slots me which I guess is related to centralization. First I'll go a bit into the centralization argument. So there are two separate arguments. First by Quintis and Connor from flashbind respectively who made this post when to sell your block. Uh and what it says is that uh it compares today's meth boost where builders built their block and they include transactions that pay parity fees. They include searcher bundles that pay them uh some me and so they know how much the block is worth and so when they bid in the market they know well at least if I bid less than what my block is worth I'll be making some money and so bidding is quite risk-f free in that sense.

However, now if you do this auction 32 slots in advance or the sale of the the execution rights 32 slots in advance, um then you you don't have this um I guess base return that a builder would get and so the builder has to predict what it thinks the block might be worth and this is centralizing because it has more risk. uh and the theoretically it also means that the is probably a more common value which leads to the something called the winner's curse and then separately there's a centralization argument made by Jonah Davin and Fahad and Malaysia Max separ separately um which I like to call no information means no specialization um so remember that in execution tickets

and execution auctions the sale is done quite far in advance so 32 slots in advance which would be about like 6 minutes Um, and compare that to today where it's done um, maybe a second in advance or maybe even less. Uh, and so today you could be in a situation where uh, a builder would win the slots because they're very very good in in an environment when there's a lot of volatility. Another builder may win when there is a lot of exclusive order flow and yet another builder may win uh, when there is some NFT spike or something. That is to say that builders sometimes have a specialization and that is when they win. But then if you do the auction in far in advance um the specialization is not so clear uh because these builders don't have information about

whether the the volatility will be very high in that that specific block or uh what the market's environment will exactly look like. And so people aren't bidding based on a block conditional on some market events like volatility, but they're bidding on a block unconditional. Um, and what that means is that there's likely to be one proposer or or just a few who have uh by far the highest unconditional expected value of a block in the future. And so there's no specialization. And that means that this unconditional expectation rules who wins the markets. Um, which then would lead to more centralization. And I want to note that these papers, they mostly apply to execution auctions done far in advance.

Execution tickets have slightly different characteristics. And there's been some great work from Mike Nutter Plafia and Tim Duck Garden who found that execution tickets are fundamentally more decentralizing than execution auctions. And intuitively this is thea case because the winner in execution tickets is randomly chosen. And so sometimes the winner is not the builder with the highest valuation. So going back to the example of having one builder that buys 10 tickets and the other one that buys 20. Probably the builder that bought 20 tickets thinks the block is worth more. uh but still there's one/3 probability that the other builder the one that bought 10 tickets uh wins uh and so this is somewhat more uh decentralized and then the next argument is multis slot me and so I'll first just

quickly recap what multisol me is is it refers to the fact that a build is more likely to extract more value if it can optimize its me extraction strategy over multiple blocks than over just one block. So imagine Alice who controls three blocks in a row. What it could do is it runs its me extraction strategy in block 99. It does so in block 100 and it does so in block 101. However, it doesn't actually optimize over all of the three blocks simultaneously. Then um this these individual optimizations are likely to be worth less than if you optimize over the entire set of three blocks. Um it's quite intuitive why this would hold. If you see that as an optimization problem,

um, optimizing over three blocks all at once or optimizing over three individually is kind of similar to optimizing with fewer constraints or with more constraints. And clearly, if you optimize with more constraints, uh, your optimal solution isn't going to get better. So your optimal amount of me attracted isn't going to get more. Uh, however, that doesn't necessarily mean as well that um, it is actually going to get more. It could also be equal. Um I think here we need to look a lot more at whether there is more evidence of actually um more me being extracted if there are multiple slots um optimized over uh jointly. Uh intuitively it would be logical if that were the case because

there's just a wider search base and so it could be that you can attach transactions uh to each other in more combinations allowing you to attract more me. Yeah, Justin. Yeah, it's probably worth uh highlighting that um if you'd like to help with this problem of understanding how big u multi-lot me is, that's that's a meaningful problem to to work on. I think we're going to get a little bit more insight um with Eve Gas. I think EG is trying to harness uh multislot me uh and we'll see from you know the market that uh bidding action whether or not it is more valuable. uh and I think we're also starting to work with some of the

builders uh to try and and get some insights but uh if you're an independent researcher interested in multisource MV do get in touch. Yeah, thanks a lot for for that call out. Um we'll we'll talk more about multisol. So I'll make a few hints of of where specifically more insights will be very valuable but I think this is one of the biggest blockers for APS currently. Yeah. So thanks for the shout outs and so um that brings us basically full circle on the background uh and we would go further on the diga um and so you may have noticed now that we started APS with trying to prevent timing games uh but now we get us a list of diga that's far bigger so actually we want to get a lot more out of APS so one

of the things that we want to get is a more competitive builder market and this could be achievable via the education tickets arguments made by like uh that I just mentioned if that's um execution tickets means that you randomly select a winner and so sometimes uh a winner is chosen that may not have the highest valuation for a block which is more a decentralized market then also we we don't want to make an APS instantiation that just leads to lots of multisol mev extraction uh so ideally we would be um even like theoretically um resistant against multisol extraction however another path is also to look at whether there actually exists this multisoft me and how large it is and yeah and then

these last two data are the no me for validators which basically applies to the timing games argument and preconfidence and so I haven't talked much about this last one but basically what it means is that we want the next execution proposer to always be known and so preconfirmations can be issued by a pre by an execution proposer if it knows that it controls a future slot if you don't know that you control of future slots, people are unlikely to buy precon information from you and you can't really sell them. And so to ensure that the preformation market can flourish, we we want that the next execution proposal is always somewhat known. And so the no for validators applies to the timing games.

We we don't want any for validators because that would be an incentive for timing games. and also the reward variance argument that Justin made in his introduction uh where sometimes a validator can win one ETH a thousand ETH or 0.001 0001 ETH uh and this is an incentive for joining a staking pool and so we we want to remove all me from validator. It's not just the time me and here I also want to quickly pause and say that this is basically where APS and EPVS connect. So EPBS is enshrined proposer builder separation which is a it's a more slightly older proposal than than APS and APBS aims to just remove the relay role and so APS also removes

the relay rule uh but it does so while also uh trying to achieve these other data and so um in PBS the relays facilitate the fair exchange between a validator and a builder where the validator gets some payments for its block building rights and the builder gets the block building right in APS. Uh this really isn't really necessary because the fair exchange is spread out over more time. So a builder pays installs N and it receives its good installs N plus 32. And so the protocol kind of acts as a relay but as a in a in a simple way. Okay. And so here is my proposal which uh I'd like to propose maybe not as the solution that that fixes APS but

as more of as a a thought experiment of what the frontier is uh of the trade-off space that we can establish and particularly I want you to keep in mind that we need to make a trade-off basically between multisol me and preconfirmation and so here's how the proposal would work instead of doing execution tickets 32 slots in advance we would just do it two slots ahead and this would help a bit with the unconditional expectation argument that would lead to more centralization. And so we use execution tickets and we don't do it that far in the head so that the block market block builder market can stay somewhat decentralized. Bids flow into block 98.

Let's say that we're selling uh the execution proposing rights of block 100. Then bids flow into block 98 as uh regular transactions and they are recorded in a smart contract. So let's say that Alice buys 10 tickets, Bobs buys 15, and Charlie buys five. Then that's recorded in a contract as follows. And then after block 98, uh the market is closed and this contract won't be altered anymore. So for the execution proposing right of 100, you can only bid in block 98. You can't do so in block 99. Then block 99 is proposed and after block 99 has been committed to. So after the execution proposer signs over it and sends it to the network, some randomness is revealed. uh which then picks the

winner from the smart contracts um of uh of the execution ticket markets and again it does so proportional to how much um the billers have paid and then this randomly selected winner becomes the execution proposer of block 100 and so um this has a few characteristics uh that yeah that I'll go to in a second um so first I'll dive more into the bidding process so as I mentioned that bids would be considered regular transactions uh and we want to do so because then they can be propagated on the execution layer which will likely enjoy more sensitive resistance than the consensus layer uh at the time of the of the beam port. So one reason that this

is the case is because of fossil. So consider transactions that are included in block 98. Potentially um the current builder of of block 98 is also a bidder in the market and maybe this builder doesn't want to have any competition uh within the execution ticket market then it would be incentivized to censor some of the some of the transactions from its competitors. Uh but uh something that we can do about that is fossil. And so since these transactions aren't timesensitive because they they are designed to um uh evade timing games uh they can be submitted on time included via fossil which is an inclusion scheme um that's also proposed for uh the beam

chain um and included in the blog. Yeah, Uh I just want to relay a uh four questions that have been asked in the chat. uh if if you do want to ask the question uh feel free to unmute but the first question is uh does this assume SSF or not uh it does not assume SSF necessarily right uh yeah from my perspective can I therefore ask then a question then if it doesn't so so let's let's suppose that we don't have SSF and we sell a slot and you have the right to propose a a a block whatever time in advance. So you bought

this right and now you equivocate and you're a builder. You're not a validator. How do we deal with safety? I mean we have an accountable safety that has to deal with this double voting double proposing how do we deal with equivocations if we don't have SSF if we haven't committed to a particular for choice. Yeah. Um yeah so that's definitely a good question. I'd say first of all the equivocations that we have today for block proposals aren't um like consensus critical in the same sense that FFG equivocations are. So we we slap equivocations on um sorry we slap slashing on block equivocations basically to incentivize people to not

uh mess with consensus in this way but it's not the same as FFG equivocations. Um so uh we could deal with equivocations of execution proposals in a variety of ways. Uh we could go the fossil route of basically if you do equivocate then all of your execution blocks are um are not considered. Um or we could do some slashing. Um I'd like to say um APS at least I mean it there definitely has to be more uh work into this but APS has less of like an impact on uh on for choice than perhaps EPBS has specifically because maybe uh we don't have to satisfy honest builder safety and uh unconditional payment for the

validator because this fair exchange doesn't happen in real time let's say so if you go back to this slide you can see that the bids flow into block 98 and the good is delivered in block 100 whereas in in EPBS you have a more difficult setting because the the bids flow in block 98 and the good has to be delivered in block 98. Uh and so not having to satisfy this fair exchange within the same block potentially makes it easier but it's definitely something that we'd have to look into more. Another thing to note is that um we don't really have SSF. We have three SF which has a latency of three slots. And so um in this case here if the fin gadget takes three slots and you know we

have a two slot uh execution target mechanism is not it's not going to help. Uh so yeah in my mind SSF and APS are largely orthogonal. Uh another question from will does this assume delayed execution? Uh it it doesn't necessarily assume delayed execution. Terrence asked, "Do you need better randomness than RAM dial?" Yeah. Uh so I'll get into that, but this uh so at the beginning I mentioned here that this proposal relies on like a heavy assumption. Uh and so perhaps it's not the proposal that should be implemented, but it's it's meant to show basically the trade-off space. And so I'll get into that into the coming slides. Uh but

yeah, so the randomness here assumes a a good randomness, which is better than the current random that we have. Alpha asks what if the bid itself is front run. Um so the bids are um like very very simple objects basically. So it's number of tickets that you want to buy where the tickets have a fixed price and the winner ID ID and that means like so if your ticket is the winner who is which ID will propagate the execution block and so um you're basically buying tickets at a fixed price. So there's not really I guess yeah your ticket your your orders are um order agnostic. Uh it doesn't matter for you whether you're front or not.

Terren but wouldn't you have some sort of like timing game because like say if your ticket is in the man pool right and then I see what other people are bidding and then I will beat right after. So wouldn't the Nash equilibrium be in a way that everyone just bids towards the deadline like right at the deadline type of thing? So have you considered like encrypting their bids or something like that? Uh yeah so encrypting the bids I think would be very nice. That's another reason why doing this on execution layer would be nice since encrypted meles are I guess have more applications on the execution layer as well. Um whether the the Nash equilibrium would be very late or very early I think it's it's not so easy to tell. You could also imagine people bidding very early. Um yeah, and

in a sense these tickets are very order agnostic and so yes, you have some it's it's nice for you to know more about how many other orders there are in the block. Uh but it doesn't uh depend on that so much. Uh and also uh there's no new information like by assumption I guess there's no new information revealed during this slot. Uh that would make your order um like more well placed at the end than at at the beginning. Okay. Now, I'll try to um go through it a little bit and if there's still questions uh I'll take them in a bit or maybe at the end and I'd love to discuss more. Uh but I think uh yeah, just explaining a little bit more now will make some more stuff clear. Uh and so uh getting back to the

bidding process, uh these bids are the number of tickets that you want and the winner ID. And so the winner ID is the the ID that will distribute or propagate the execution block if this ticket did indeed win. And so that's nice with encrypted meles because that means that the sender doesn't necessarily have to be uh the person who would also be the winner of the auction. Um and so uh the sender address might not even be encrypted in encrypted meles and so the win ID would be decry uh encrypted and so then getting to a bit more of the specifics of uh the market uh I would propose a fixed price flexible supply market and there's been some work uh notably by Christo Tradel from flashbots who showed that this is a a better market for decentralization uh and

competition compared to having a flexible price fix um fixed supply and we can make the price very low. So for example, one way uh and then bids are committed to two two slots ahead instead of the 32 slots ahead which would be better for some market competition arguments as I've laid out before uh doing this on execution layer where we don't care as much about the timing games that happen. So remember APS is a is a response against beacon proposer timing games and so the timing games played by those that are also attesters. We don't want attesters to play timing games because we have an honest majority assumption on the testers. But we don't have an honest majority assumption on the execution proposers. And so APS doesn't actually

get rid of timing games as a phenomenon. It just means that there's no beacon proposer timing games anymore. There could still be execution proposing games. Uh but since all of this lives on the execution layer, the bidding process lives on the execution layer. Uh this doesn't hurt the honest majority assumption that we have on the testers. Uh and then finally um we we use the censorship resistance that's on the execution layer and in that sense we get me burn for free which is a sentence that's more often um thrown around with APS and here the for free part means that we don't have to implement another availability committee that you would have to do with meburn um and actually fossil and meburn look very similar as

in they say we um it's it is a committee of of people who say we have seen mean certain bids at certain amount of time and they must be included in the block and so yeah they they look very similar and in that sense we don't have to do the work of implementing another meth burn mechanism yeah Justin so Enrico asks a relevant question um can these bids fill up the fossil capacity if so will this reduce the user transaction sensor persistence capacity yeah so I I wouldn't say they would fill up the fossil capacity Um so fossil doesn't actually increase the supply of of gas that a block has and um a blocks today have a supply of

36 billion units of gas and then there's the 1559 mechanism that aims at uh creating enough demand to satisfy basically the target. So the the base fee fluctuates such that on average there should be about the target limit uh the target amount of gas uh demand and so fossil doesn't affect the amount of uh supply or demand there is necessarily. Um, and so these tickets, they could just be included in Fossil. And Fossil has about 128 kilobytes of um, room available within uh, across the 16 inclusion lists. And if I understand correctly, blocks are around 100 megabytes uh, today. Uh, and so uh, there should be more than enough supply

in fossil to be able to get all of the transactions uh, into the block. That being said, I guess these transactions they do consume gas uh and so they do consume some network resources. Uh doing it on a consensus layer, however, also consumes network resources. So if you do this on the consensus layer, these bids also have to be processed. And so potentially there are some differences here, but I think in like from first principles, uh they should be using roughly the same amount of network resources.

Okay. Yeah, Justin, was there anything else or um so data always asked the question um does this mean we're only burning the MEV from public mele transactions? And I think it was answered in the chat whereby Fossil is only used as a censorship resistance gadget. It's not used as an MEV oracle. You can still use whatever external information you want to price the bits. Yeah, exactly. So um yeah fossil is not the meth burn part.

Uh it's yeah it's just the inclusion uh which is similar to meth burn I guess. Um the amount of mev that is burnt is just the number of tickets times the price at which the tickets are sold which is irrespective of and then getting to the winner selection part. Um we do this thing where uh the smart contract contains uh the bids uh or the orders for the amount of tickets and then after block 99 is revealed um some randomness is revealed that is applied to the smart contract to pick the winner. This is a relatively complicated setup. So I'd like to explain why um this setup might be nice if it if it is feasible. Uh and so first of all, we'd have a minimal look ahead. Uh and so the

the block proposer of block 99 doesn't know who would be the winner of uh the block of uh the execution block in slot 100. And so this means that while building 99, you can't optimize over slot 99 and slot 100. So you can't extract multisol me in that sense. And so that's quite a hard guarantee. it's it's just um it's just not going to happen regardless of whether there is a lot of multisol me available or not. And then finally why why we don't pick for example the winner in the beacon block of source 100 is that we want to enable preconfirmations as well as possible.

And so for pre confirmations we want that the next execution proposer is almost always known. Uh and this is the case uh here. uh and the only time when the next execution proposal is not known is with this delta t which is the time between uh the release of the execution block 99 and that the randomness is revealed and so getting this delta to be as small as possible would mean it's better for preconirmations. Then finally I guess the um the elephant in the room has been this randomness and so this randomness is a big assumption. Um, one way that we could get it is using a threshold committee where uh, a threshold committee reveals randomness after the execution block has been revealed. But this imposes a livveness assumption

which would be a a large decision to make and even though it it might be possible and it might have some other uh, nice use cases. It is a big assumption to be aware of. Another way that we could go is using encrypted meles and using the postate route uh, as as our randomness. So let's say that a transaction is included in an encrypted way into a block uh and then decrypted afterwards uh and I guess executed or or um maybe the the decrypted version of that transaction or the decrypted version of a set of transactions is used as randomness. uh then you then the builder of uh the execution block of slot 99 doesn't know um the yeah the the contents of the decrypted version of

what they had included in encrypted way and so usually encrypted meles also rely on some sort of threshold committee but there are other options like sealed transactions from anders which is an ETH research post which you could read but this is also no free lunch so there are some uh considerations with me issues potentially uh so yeah I just want to emp emphasize that this randomness is a is a very big assumption and not something to be considered lightly. Why I still propose this is to show basically um uh the fundamental trade-off that there exists between multisol me prevention and pre-bomb friendliness. So in the following I'll propose two other um um APS implementations which um go for either

preventing multisol me completely or uh ensuring that it's very friendly to pre-drformationations and these two don't rely on randomness. So the randomness is only necessary if you want to both prevent multisol and have preformations. If you want either of the two you don't need it. Are there any questions on that? If not, I'll move on. Okay. So, uh then um I'd like to present execution tickets, which is basically the same as the the execution tickets proposal that we've seen before.

Uh and I'd like to say that this is basically the way to go if you want to optimize APS for preconfirmations. And so, uh the mechanics are fairly similar to the previous proposal. Bids flow into a block. They can be uh execution layer transactions sorted in the smart contracts. It could also be done via the consensus layer. It doesn't it doesn't matter too much. But then if you do it on the consensus layer, you need to ensure that you have some more sensitive resistance uh which is doable in this setting. Uh then some blocks later um randomness is revealed and in this case we could still use the randow that we have today. Uh and that means that um with some sort of randomness which is biasable um the winner is chosen of who

will be the execution proposer port 100. And this winner will be known for some time between the block that the randomness is revealed uh and the block that the proposer has to propose. And so because the proposer is known during that time, it can sell pre-conformations to users. You could do so for example 10 minutes in advance um so that proposers or yeah so the execution proposers can sell subscriptions or other fancy types of pre-confirmation use cases. Uh but yeah, the trade-off here is that because you have this look ahead, uh you have multis source me and so that that goes to show that um the look ahead is is like fundamentally necessary to have preconfirmations, but it's also fundamentally the problem for

preventing multi-lot me. And then you could also go the other way of saying we don't care as much about preconfirmations and we just want to ensure um that there's um no multis slots maybe. And I think the best way to do this is to host an auction in the beacon block of 100. So note that this mechanics are quite different from the previous proposals as in here the it's an auction and it must be done in the beacon block of 100. So in this case bids flow in um and me burn is used to observe all of the bids that exist and say all of these bids must be included in the in the beacon block and again the proceeds I guess are burnt. With this uh we can't do execution tickets anymore

because we don't have this randomness that was just revealed. Uh so we would do an auction uh and just an auction in which the the highest bidder wins and those that lose they don't pay their bid. Uh and so you can sell the execution proposing rights for block 100 in the beacon block of 100. Uh but the problem here is that it's slightly unfriendly to pre confirmations and that is because uh in the time difference between the execution block of slot 99 and the beacon block of slot 100 uh there is a time where the next execution proposer isn't known and so that's signified with the delta t here and that means that in this time period the users can't receive quick confirmations which would mean that the average uh time to inclusion would be higher which is bad

user experience. it is like really really good against multis slots me because bids come in after the last execution block has been committed to and so you can't optimize over multiple blocks because even if you were to leave open like a multis slot me opportunity in block 99 uh then you would basically have to bid for this for what you left open again uh in block 100 and so you can show that multisol me is it's it's yeah unincentivized to extract multisol me a downside here is that we do need an additional availability to committee to uh ensure that meth burn is possible uh because the bids are on the consensus layer and so here again uh I want to show uh how this relates to to the

earlier proposal with the the the very good randomness that I assumed. Um so this the jet execution uh execution auctions uh was basically the proposal that I was working with before. Uh but if you want to decrease this pre unfriendlininess to the minimum possible uh then what you could do is choose after like the best you can do is choose just after the execution block of slot 99 has been revealed uh to decrease this delta t. And to do that you need to do this randomness basically. And so uh the randomness shows basically like you can't you can't do better than that. Um so you need you need to make a decision there. And so in summary um Justin had proposed in in chatting with Justin

there came up three tracks. Uh one is the randomness track. So looking whether this randomness is indeed possible. uh doesn't it impose too much livveness assumptions on Ethereum like do we actually want this uh and maybe is it useful for other applications in that case it would be interesting to explore further uh the first proposal if we find that this randomness is just impossible or it's not a trade-off that we're willing to make then we have to choose either preconfirmations or preventing multisoft me completely and to inform this decision that's really the the crutch of what we have to do uh in in the coming time And so Justin mentioned that uh multisol me is really uh an area where people can contribute and I want to

reiterate that poll. Uh so some interesting work would be like to see is multisolv really a big deal or not. Um and that's also something that we can learn over time and similarly whether preconfirmations will gain adoption. And so that's to say we basically need to make a trade-off here. And then finally, do we still want APS? Because it's become a bit of a a lower um lower volume topic, I say. Um I think that's partly because we've seen that timing games at the moment aren't uh that big of a deal. This is a photo from Tony's timing. Pickics and it shows uh over the what is it the last 14 days um the amount of ETH profit cumulatively uh that proposers have gained over time.

The green dash line is those that do play timing games and the red dash line is those that don't play timing games. And you can see that the green line has been above the red line for most of the time period, but then they converge and there there's quite a little difference there. So perhaps uh time gains are not that big a deal currently, but they may be in the future. Of course, that being said, APS is still interesting because it does remove Vays, which EPBS also does. um and and it does implement me burn which is uh independently desirable as well. However, potentially we need to use either no multisource me or precom friendliness and so that decision is something that we need to work on. Yeah.

So that's all for what I had. So thanks a lot for your attention and as Justin mentioned there's this website aps.directory which contains um as as far as I'm aware an exhaustive list of all of the APS work. Uh, and you can find me on Signal Telegram here if you'd like to be contributing to this work. Amazing. Thank you so much, uh, Julian. Um, on the topic of having to make a trade-off and potentially waiting more time for us to to gather more information and make a more informed decision. Um, a potential strategy here is actually to have multiple APS subspecs, you know, version A and version B. um and then just pick one or

the other closer to the to the beam fork. And the good news is that APS is not super complicated. I mean maybe there is a bunch of complexity hidden in in the randomness gadget. Uh but um if we assume no fancy randomness, you know, there's these two flavors that we could could go with and we could even potentially have a third flavor assuming the the fancy randomness. So I'll just repeat a question that was answered in the chat just for the listener. Um do ticket prices go up and down depending on demand?

Uh yeah. So um I'd say in principle that's a design decision. Uh there's been some work now showing that it's uh it's nicer to just have a fixed price. Uh and so I think for now we should go with just setting a fixed price that's very low. So there's always at least one person waiting to buy a one ticket. Um and then letting the supply be flexible and it it can be shown then that that's better for market competition. It should be I guess one thing here to note is that there's two variants of execution tickets. There's one which if you've been selected as a ticket winner, your ticket is removed from the pool of tickets and then there's one where you know it's it it is not removed. I guess

you could call the second version execution staking which is basically you have a number of units of of of guay uh and then your probability of winning the auction is is proportional but when you win you don't lose uh any of your stick and here the way that you pay is uh through opportunity cost I guess yet another flavor of execution staking would be uh in addition to paying with opportunity cost there would be uh some sort of uh negative issuance curve. Um, and so for example, if we're going to have at most

1 million E staking to become execution proposes, we could have uh a curve that goes to negative infinity uh around 1 million uh cap asks, but then you should be able to buy multiple tickets in one transaction, right? Arbitrary many tickets in one transaction. Yeah, an order can just specify how many tickets they want.

Lis asks, would you mind repeating why in the JIT execution auction scenario would the competitive execution proposer market assumption would still be satisfied? Yeah, that's a great question. So, I'd say um the competitive market assumption is is something that's uh it's hard to make very explicit um and and precise I guess and it's all on the spectrum. Um so, uh what we know about the competitiveness is that execution tickets is better than execution auctions. uh and doing it uh closer to uh the deadline. So doing it just in time is better than doing it far in advance. And so what you're trading off here is you can do execution tickets but then you have to do it further in advance basically. So execution tickets

is better uh further in advance is worse or you can do execution auctions which I guess is worse and uh just in time which is better. So the the trade-off is uh is there but it's hard to quantify what exactly the the outcome is. So Matt asks, "At least to me, it sounds like we're trending more towards a pre-comm is a huge deal."

Um, yeah, I'd say so probably. um they're to some extent both um like an induced demand type of arguments uh like pre-confirmations we don't know yet how large they will be at what time frame uh but there's definitely lots of potential uh and then multi source me I mean we don't know how much is possible today uh but there might be some early um signs that that it's not so much uh but I'm saying that very carefully and it's something that we need to consider more I mean one consideration question is um whether or not access to flow is the predominant thing that determines centralization as opposed to multi-lot MUV.

Um, and so it's possible that it's not a huge deal and it's, you know, relative to to other things. That's yeah, that makes sense. But I'd say multiolor MV is not also a centralization argument necessarily. It's it's also just mostly like a bad user experience arguments. And so there is like the centralization part which may be dominated by other factors, but separately it still has some negative functionalities. Right? So two two more things we'd like to know about most of MVs. one uh will it materialize in the current market because in the current market we do have a look ahead of let's say 32 slots and so in theory we could have multi-lot me um and then the second thing that would

be nice to know I forgot what I wanted to say um any case I'll come back uh Mark asks uh how close are we to having the fancy randomness we need with VDFS. Yeah. So, I'd say um here we probably can't rely on VDS. So, I I said like threshold committee or doing this sealed transactions thing um with encrypted meles that doesn't rely on a threshold committee. Um VDS here are a bit tricky because you have to get the timing very very good. Uh that being said, I'm no expert on VDF so perhaps Justin can say more there.

Yeah. Yeah. So if you want low latency randomness, BDFs is the exact wrong tool that you that you want. Um yeah, the only way that I know to get low latency randomness is using threshold cryptography and that has all sorts of of complications. One of them is that you need a fallback for livveness. Um another one is that it's unclear how to do threshold cryptography in a postquantum way. Um most of the solutions I know use uh elliptic curves. Um and then there's also an attributability problem which is that if there is collusion and the the threshold assumption is not held then you actually can't detect uh that there is

collusion. So um yeah it it is definitely a powerful tool potentially but it's it's also one that that comes with trade-offs. And I did remember the the thing that I forgot which is um it it would be nice also to see um how the applications find ways to defend against MEV. Um so for example we might see batch auctions or we might see you know custom sequences and that might inform also the the multisot discussion.

Lotus. Yeah, I wanted to comment that uh to to study the centralizing force of having the auction predicting for the future. Uh we can actually get hard data now in how it's going to work with the fast lane in Aron for example where you have uh beaters for the next minute. It's not exactly the same as APS, but the market dynamics might be similar where people with information are betting on how the market's going to move in the next minute or so. Yeah, that's a very interesting point.

Thanks. We should study. And another um market that might yield insights is Solana. And the reason is that Solana has four slots in a row um per proposer. And so um yeah, we we we we might see, you know, a very sophisticated market say um you know, I'm willing to reserve the first two at a different p price than kind of reserving each individually, something like that.

Okay, we're exactly at the hour and there are no more questions in the chat. I'll just give it a few more seconds for questions to come in. otherwise. Um, thank you so much uh Julian for for the the great discussion and uh yeah, in a couple weeks we're going to have 3SF as a topic. Thank you so much everyone and uh have a great day. Bye. Thank you. Bye. Bye. Bye. Bye.