FOCIL Breakout #11

Transcript

[Music] Um yeah, I think we can well the recording is already started but maybe we can just go ahead and start the session. Nice. Thanks. Uh so welcome everyone to Fossil breakout number 11 I think. Yes. Um today we're going to have a presentation by Michael on relay inclusion lists. Before this uh just want to tell you about the few updates related to Fossil.

Uh yeah, first I think I mentioned it last time but uh we are planning the false session during the Berlin interrupt which is going to be in uh June uh exactly on wait let me check exactly the day it's going to be on Wednesday the 11th I think. So for those of you who are around, you are of course invited and just uh DM me and let me know and I'll just like tell you the exact time and location. Um most speakers have like confirmed uh and basically the sessions are going to be um fossil implementation progress. Um we're going to have one by that's going to be by G Jun, one on

fossil synergies with other EIPs. Um, that's going to be by Franchesco. We're gonna have one on Fossil and Statelessness by Carlos. Um, one on ZK Fossil by Benedict. Uh, one by Fossil and the future of nodes by Barnaby. Uh, so I think that's going to be very exciting to just like talk about all these in in person. Um, and yeah, if you are around, just join us. I think would be be fun. Um yeah about like the fossil synergies another update is like sort of like the progress made on the interaction between fossil delayed execution and uh block access lists. Um

it's nice because basically if you have block access list with post transaction values um that mostly allows attesters to statically validate uh blocks and especially like the fossil conditions uh in a much like simpler way that than before. Um, so I mean Tony and Franchesco I think I'm mostly working on this. I've been just like following along and providing inputs but um yeah it's it's just like nice to see that a couple of like different EIPs actually make uh make it easier for each other.

So that's something I think we need to follow up on. But um uh yeah, I think it's it's just like nice. Um yeah, just also wanted to highlight highlight one of Balik's post about the local node favoring delta to the scaling road map. Uh I recommend checking it out because it's actually quite related to uh VOPS so validity only partial statelessness uh something we presented during a previous breakout room. Um and you know in the comments there are like sort of like a lot of discussions and back and forth on the future of Fossil and what Fossil can be like and how it

interacts with um full native contraction. So yeah if you have opinions or want to comment or participate in the discussions uh you can check it out there. Um, other update I think it's also nice to highlight when new people join like Discord conversations and it's been the case lately. So yeah, um, it's just like great to have like more and more people engaging on on this and like asking questions and being curious about Fossil. Um, so if you have any more questions, you can also ask them during this breakout. Um, and yeah, I think

that's mostly for me. Um, are there any questions on any of these small updates? No. Then we can uh go ahead and with the presentation. So I think yeah, it's going to be Michael on relay inclusion lists. Yeah. Hi guys. Uh we are sharing our screen. Uh it should be in in a second.

Okay. Uh just to confirm, can you guys see the screen? Yeah. Okay. Perfect. So first of all, thanks for the opportunity to present our design here today. Um relay inclusion list. We have a post up on E research and thanks also to everybody that provided feedback on this design. Um we can also then continue the discussion on E research. There's already some uh some good exchange of ideas going on there. Um but in any case without further ado uh let's jump in.

So the agenda for the presentation is to first quickly describe the goals of relay inclusion lists. um specifically what we want to achieve here. Um there's three goals and we'll walk over them first. Then to sketch out the design that is the architecture of the system and then there's basically two more or less discretionary dimensions uh which we'll deep dive separately. And the first of those is what transactions to include. So the inclusion rule and then the second is how many transactions do we include? Uh which is the sizing question. the the size of the inclusion list in terms of network size. So bytes specifically and then lastly we want to

talk quickly about the future directions. So the design goals well first we want to use relays to immediately improve censorship resistance. Um and we want to do this in you know a certain a certain aligned way. uh first we want to avoid introducing protocol changes or other technical complexity which would make the design forbidding. So specifically our goal is to have something that could be applied tomorrow and immediately start increasing censorship resistance adding value in this type of transparent way. Um we also don't want to introduce qualitatively new trust assumptions. Um

what that means is that really inclusion lists can be accomplished by the existing actors in the PBS pipeline and validators wouldn't need to trust somebody new they also wouldn't need to make a decision if they trust somebody more right so basically the relays that they would be using these would be the relays that would start delivering relay inclusion lists and lastly one thing I want to highlight we ideally would like to see relay inclusion lists as a baseline So there should be a new default feature for non-ensoring relays where the validator may opt out if it really desires that. Um but generally for non-ensoring relay the it should be it

should be uh building uh relay inclusion list by default. Uh now the second goal uh of the design is to prepare the block production pipeline for a future in protocol inclusion list. Uh put a different way, relay inclusion lists are not a a substitute for in protocol inclusion lists. We we see them as a logical step in this direction and a quick step. Um what that means in practice is first we want really inclusion lists to roughly reflect the fossil specifications and the way we would like this to reflect is that the risks of the design are you know incremental right there something that's

rolled out step by step. there's testing and it's done offchain and and then and then this would result in a seamless operational roll over to Fossil. Um if I put it in practical terms, if yeah in protocol inclusion lists come about um builders relays would know how to how to yeah would would know how to coordinate on on such a list being uh being built and this is not just technical. This is also things like building dynamics and then lastly to we want to achieve these two overarching goals in a sustainable way right and which means that the relay inclusion list at the beginning uh should preserve relay competitiveness or

put another way propose a riskreward. Okay. And one thing that means is uh what I mentioned initially no additional load on the proposer. Um and then secondly, block value should not be meaningfully decreased, right? Because if the relay inclusion list were very large and would add a lot of latency and the block value were to decrease, this would uh this would just make the relay less competitive. And in this way, timely inclusion, you know, would would kind of decrease over this this separate axis of just the relay not winning the slots. Um but we we think we have a a good way of uh approaching all three of these goals.

Yeah. The design overview um you see it sketched out on the right there. And again one one goal for this is to be quick and that means it needs to be transparent and simple. Um there's basically three kind of three steps and they're preceded by a setup um which is that non-sensoring relays by default should build relay inclusion list for all proposers with that optional opt out. Now once the setup stage has been completed um what would happen is for each slot the relay observes the mempole and then uh ranks these transactions via a deterministic inclusion rule assigning

a score to each and the inclusion rule is something that will be discussed on the next slide. Uh so I will skip that part for the moment and instead focus on the general setup. Um then once the relay has derived the weighted the list of transactions ranked by inclusion score it would fill the inclusion list with the respective top ranked transaction until the relay inclusion list size remmit has been reached. Um and then lastly once the list has been built the relay would expose a API endpoint that builders can use to fetch uh the inclusion list. Um so this is part one at the beginning of the slot

and then there's part two which is after the builder has seen the inclusion list and has started to has reflected it in its block. So this is when the builder delivers the block. Um then the relay simulates the execution. So first the relay checks if all transactions in the inclusion list are included in the block and if a transaction in the inclusion list were not included in the block the relay would simulate its execution against the block's post state and then if any non-included uh transactions pass standard pre-execution validity checks uh the block is invalid and rejected.

Right? So this is a strict condition. Um thirdly, uh if uh if a builder is optimistic, the relay might not be able to reject the block in time. Instead, what would happen is there would be a penalty enforced against the builder. And the way we propose handling this penalty in our research post is that it should reflect the block value because factually the block would be for feed for feeders. Um there's another question that came up in previous discussions which is what happens if the builder's block is already full. Um this would not be a scenario that we would be um concerned about at the moment because

the builder would have the list of transactions in the inclusion list um available at the beginning of the slot and therefore should as part of standard procedure sorted into its block which means that the block wouldn't be full without the transaction on the relay inclusion list being included. Um now the the next thing is the inclusion rule. So and we're quickly summarizing two options here. Um option one which by the way thanks for that uh Anders has proposed on E research is a lot leaner than option two. Um I kind of refer to these options respectively as

multiplicative without normalization. that is option one and normalized and additive which is option two. Um for option one I'm not going to deep dive both of them right now but I'll just quickly summarize it and then we can uh examine it in more depth maybe in the discussion afterwards or an e research or async. Um option one basically uh computes the inclusion score over the waiting time of the transaction in the mele and the priority fee of the transaction as a multiplication of uh of each attribute. Optionally there could be a weight added for each attribute.

For example, if you were to want to say that the priority fee is more important than the waiting time, uh we could reflect this. But initially we would assume uh that the weights are zero or put another way that they're equally important. And the logic behind this is that we say you know inclusion this happens over a time axis. So we wouldn't want the transaction to sit in the me pool forever and but it it is also a function of how quick the transaction wants to get in uh which is the prov component and then the inclusion score that will have to that will have been derived uh would be adjusted by the total gas paid per transaction. Uh put

another way uh we would want to maximize uh the the the space that is still available in the inclusion list. It's worth highlighting here that the inclusion list is measured in network terms. So in kilobyte um but the final adjustment here would basically be saying well the block space the block space has to be uh has to be maximized in terms of value. Um then there is option two which is normalized and additive. Uh again one key difference here is multiplication of the waiting time and the fee or addition of the waiting time and the fee score. Uh the implication of multiplication is that uh

a transaction which has a priority fee of zero would not find inclusion. uh whereas with addition this would be this would be uh the case. Um then for the addition rule we would again begin by examining the waiting time and the priority fee and we would normalize it by the median uh waiting time or priority fee for all transactions pending in the mele. Then we would compute a simple additive score and divide that by the bite size which would be a way of maximizing over the networking constraint. Um so to quickly summarize the slide here before we go

further. Um the difference between these two rules would be multiplication or addition which is a statement of you know does a transaction that only needs to uh that only pays the b base fee should that transaction find inclusion. Um it is also a way of uh kind of handling uh manipulation resistancy in in different ways. um multiplication without normalization has some spam resistance built in. And again, transactions are compared to each other in in both scenarios. Um and then the inclusion score by total gas paid or by the transaction byte size. This would be an implied statement or what the what

the bottleneck is, right? Is it is it block space or is it networking? Um where the byte size would be networking and then block space would be measured in in gas. Um generally our feeling is that these are both appropriate ways of approaching it. Um we find option one quite lean and and elegant. Um but generally we would see this as a discussion kind of with the with the stakeholders and then we can come to a a final decision from there.

Um the next point or the next kind of parameter decision is the sizing of the inclusion list. Um and there's basically one overarching goal here which is that the size of the inclusion list shouldn't really meaningfully affect block value or put another way uh decrease block value. And the context here is that block value decreases with increased latency. And then latency of course scales with the size of the inclusion list. Um this kind of foreshadows the point that I made at the beginning which is that relay is providing relay inclusion list must must stay competitive right to ensure timely inclusion and to ensure the the design

finding continued validator adoption. um which is the reason why we initially propose a shelling point which is the uh constraint proposed in the in the fossil specs um which is lean. Um with that said, relay inclusion lists have a big advantage over proposaldriven inclusion lists um which is that they're not constrained by the proposal bandwidth, right? Which is the second point on the slide here. And what that means is as real inclusion lists become more adopted, they can support larger sizing.

Um, one reason for this is that the opportunity cost of opting into relay inclusion list decreases for uh the more relays run it and therefore they can't be larger, right? Because you don't have to compete with with relays that uh opt out of relay inclusion lists on latency. If if everybody competes on the same terms, uh it's possible to to raise the size without incurring cost. And the second thing is the bit curve can shift to accommodate the the marginal latency uh that really inclusionists add. So basically if I know that the block will be sent around a little bit earlier, I can provide my my best bit a little bit

earlier. Um and then just to wrap it up, uh we think there are some promising future directions here and first of all multi-relay inclusion lists. Um what this would mean is there could be a shared inclusion list that can be built from the inclusion list computed by multiple relays. Um one advantage of this is that it improves censorship resistance uh by enforcing uniform application of the inclusion rule. Right? So there couldn't be a single relay which kind of builds the inclusion list to um to maximize it's you know for whatever goal it might be pursuing there's there's a lot more there's a lot

more assurance that the inclusion rule is is applied um consistently and then because it it is also the same for each relay um the playing field would be even and then secondly if each relay builds in inclusion list only locally. Um there's a chance that builders want to keep a lot of functionality, right? So they might build one block for relay A and another block for relay B. Uh under multi-relay inclusion lists, they would build one block for all relays. Uh which reduces redundancy and and then again also unlock some efficiency in in this way. Um the other two directions we see uh relay inclusion list for blob type

transactions and lastly what we mentioned before uh larger larger relay inclusion lists. Um to uh conclude the slides there's some further reading here. Uh the first is the E research post uh which I would encourage people interested in this idea to uh consult. And then the the post has a couple of references that we make all uh very interesting reads which which are listed um below it. So I would uh suggest uh checking this out too. Um yeah so that's it from my end.

Great. Thanks a lot. That was uh that was really cool and yeah very nice to to see that you guys have worked on on the inclusion list. uh side of things for relays. Uh also that the work on Fossil was useful to to build that up. It's very nice to see. Um I have quite a lot of questions but I want to give the opportunity of other people to ask some first. So if anyone has some, go ahead. Sorry, just a random question. I want to

know could the relays prioritize um certain transaction like inadquently introducing new centralization risks like um relays becoming gatekeepers or something like that. Yeah, sure. So, this is uh something that uh we want to avoid and there's one uh there's two key key steps that have to be taken to avoid the relay kind of making these uh discretionary decisions. One is the inclusion list uh inclusion rule has to be very simple. So, there's not a lot of room for discretion, right?

So the relay applies it each relay applies it in a way that is uniform. And then secondly one of the future directions we outlined which is relays talking to each other. Uh that helps with that too because if relays collectively decide on the final inclusion list then individual relays have a lot less power to kind of skew the list into a direction which which they would prefer. Okay. And one last thing is there like a possible interaction with proposal build um separation especially if the builders ignore relay um less to maximum me.

Yeah. So um I mean the the entire design is um like purposely built such that it fits onto the current PBS uh supply chain. Um and so yeah the intent is just to communicate these constraints or the inclusion list to the block builders and they have to adhere to it. So unless there are relays that don't support it um basically for a given slots if a proposer connects to these relays a block will not be valid. So um it essentially is purposely built for the PBS supply chain as exists today. Nice. Okay, I will go ahead with some of

mine. Um, yeah, just want no this is more of a comment, but just wanted to point out that the fossil size is 8 kilobytes, but there are like 16 of them. So, you know, if there are there is no overlap that will actually be 16 times 8 kilobyte. Um, but I know bandwidth is a concern. I just wanted to to sort of like make that clear. Um also like that was in in your last slide but uh but blob is would actually be really really cool. Uh it's more bandwidth for sure. Um I think it's actually around the side of like 16 times 8 kilobyt um for one blob but you know fossil

doesn't support this in its current form. We have ideas of like protocol ways to get better sensor resistance for blobs but it's it's really not there yet at at least like not at the same stage as for solids. So yeah I mean I think that's a very exciting direction. Um and then yeah there was more comments but if you have any answers. Yeah so quick comments on the um the blob IS. So as you said correctly the biggest concern is just the size um and the additional latency and hence preventing adoption or like putting relays that um basically adopt this um

like in a worse spot in terms of competitiveness. Um that being said um we're currently already exploring optimistic v3 um for relays which essentially means um that the builders can submit the headers uh without submitting the payloads which effectively means they can like on a low latency basis keep updating their bits without having to shuffle the entire big block payload. And so under optimistic v3 the size of the block at least from a latency perspective um in terms of submitting bits to the relay should have zero influence and once that is live I think u basically blob inclusion lists

also become viable nice okay that's pretty cool uh and makes sense for sure for for the side of size of it uh also yeah I understand the gradual process into um making sure you have some adoption before you increase like the the bandwidth for sure. Um, nice. Uh, does anyone have any other questions? Otherwise, I'll just keep going. Okay, I'll keep going. Uh yeah, I just wanted to no for the inclusion rule. I think I don't I didn't get why the multip multiplicative regime uh didn't have the transaction size as a an input

and the additive did because the transaction size is not only like a I don't know an optimization. It's also to avoid um that also allows to avoid the IL flooding like you know you can if you submit like a very very large transaction that gets p picked up and that takes like the entire inclusion list um and then uh you are able to invalidate it uh that sort of like crowds out other transaction and that's an attack we want to avoid. So like sort of like filtering by descending order of by transaction size uh is anyways a quite good idea I think.

Yeah thanks for the comment there. I think this is very valid. Um the so basically there's uh there's two things we considered. Uh one is uh where uh in option two we are we are adjusting by transaction size um to kind of prelude uh this vector that you mentioned right where a single transaction can come in and and clock up the the space on the inclusion list. And then uh the the angle from which we approached uh the other adjustment in option one which is over the gas is we were saying well what do we expect to be the bottleneck in practice? Would it be the networking constraint or would it be the the block space constraint? So kind of which of

these is more is more limited and then we should we should maximize over the over the constraint. Um the option uh with adjusting by gas uh to some extent also favor smaller transactions if we say that they they have less gas um but of course in a in a less direct way. Um I think in summary we don't really have a final intuition yet on which of these approaches would be best but it seems like there could be a hybrid approach there uh where we where we adjust by you know by by both to some extent or we have a threshold uh to ensure that uh this this attack where somebody can clog

up the block space uh does not happen but at the same time we we maximize the utility of the remaining block Nice. Yeah, that makes total sense. Uh ah and there is also and there's comments on on E3 search apparently that compares these options. So I will look into this a bit more. Thanks. Uh and then more general I think high level questions. Um what will happen to relay inclusion lists if or let's be optimistic when fossil makes it in the protocol.

Yeah, I think uh the from our perspective then it would just be deprecated. Um and uh what um Michael mentioned earlier, the I guess the upside of having the some of the actors across the supply chain already supporting inclusion list is obviously builders will have um adopted them, but also the relays in terms of um having to validate blocks based on inclusion list and things like that. But like actually gossiping or like needing to maintain and generating the inclusion list, but then from my from our perspective currently being deprecated.

Okay. Yeah, that makes sense. No, no, the roll out makes total sense. I I was just sort of wondering okay what happens because then it it will feel a bit like a double like I don't know repetitive sort of thing. Absolutely. I think like in protocol is obviously much stronger and so like yeah there wouldn't be any need anymore. Okay, nice. Uh thanks a lot. Uh any other questions from from other people or should we move on? I have a question. How do we make sure relays build relay including the inclusion rule correctly? Uh what I want to ask is is there any gadget that

prevents relay incl? Yeah. So um uh to to summarize the question if I understood it correctly was uh how we ensure that relays apply the inclusion rule correctly. Um I think one way we've approached this is by saying the relay is a is a trusted party and the validator enforces this trust against the relay. Um so if a relay were to to misbehave ideally the validator should should opt out. And then secondly uh once the the uh relay inclusion list can be shared between multiple relays.

So multi-relay inclusion list the the last point on the uh last slide um this this vector would be offset to a large extent because then relays build one inclusion list collectively um again reducing the discretion each individual relay has over the inclusion list. Yeah. And the other factor is that given that the inclusion lists will be made available publicly which is how the builders will or which is how they will be communicated to builders. Um if there's any massive outlier uh i.e. um some weird transactions that were never seen on the mess that ending up on the inclusion list and things like that. I think uh builders will pretty quickly spot it and call relays out and then

again it will be a huge reputational damage which I think is one of the key things that relays optimize for Got it. Thank you. Right. Thanks. I guess another sort of like out of the box idea is like to use a T um but might be a bit of overhead and I agree about like the trust assumption being sort of the same like if you trust the relay you could also trust it for building inclusion list according to the rules they have specified but uh great okay thanks uh yeah again great presentation thanks a

lot for coming in Um should we move to implementation updates? Um I don't have any super specific thing on the agenda but I'm I'm I I am curious to hear if there are like sort of progress across the board. U whether it's testing or implementation uh on on clients or interrupt what's uh what's the status of all this? Um, yeah, I would just I can say a couple of things. Um, first, I think we should try to get this uh PR uh authored by Mark merged in as soon as possible. Uh I think there's been a lot

of uh comments on that and I think it's okay if we just want to like limit scope and open a subsequent PR as long as we address kind of like the core aspects of uh what's happening on the execution layer. Um and then yeah I have a draft BR up on the execution specs. Uh I will need to do a rebase uh on top of the latest uh Osaka fork over there which didn't exist at the time that I opened it. Um and then I'll have to yeah depending on what what gets merged into the EIP. U maybe make some changes. Um I've also been working

on the execution spec test. Should have a PR up in the next few days. Um, again, this is another thing where it'd be nice to have this uh PR for the IP merged. just so we're all operating um from the same Yeah, from the same EIP essentially. Um and then yeah once that's um ready we'll be able to have some test fixtures in the engine new payload format and then yeah I will validate those with either WH or or GU uh uh the RET or GU fossil fork uh

before before the PR and then other clients can uh consume them and validate them. Um, but yeah, I think the main thing uh is just try to get the the PR uh merch um in the next day or two would be great. I can uh take a look through these uh review comments today. Great. Appreciate that. Um yeah, that's that's all I have.

Nice. No, that's awesome. Yeah. Yeah, I remember there was quite a bit on the PR, but I haven't looked for a while. So, I'm happy also to take another look today. Uh, see if I see anything. And yeah, agree. We should get merge code. I I did see Yeah, new people coming in also and being a bit confused about the execution part uh of the EIP. So, would be nice uh to have it merge. I agree. And then what I just didn't really follow what was the so like first PR not the spec test one but the the first PR was about uh that you need did need to replace on on FA

uh the execution specs uh yeah I can share a link to that PR um but essentially it's just you know taking what's in the EIP and yeah Thanks. Okay. Making it so that we can create test against it. Um and yeah, just a more formal version of the um of the IP or at least the execution layer aspects of it. Um, however, yeah, the diff shown is quite large because I had to add a bunch of Osaka boiler plates, but now that there's a upstream branch with that, uh, should be able

remove uh, a bunch of that. Nice. Yeah, that's awesome. Okay, great. Thanks a lot. Um, and you have been talking to the steel team, right? Awesome. Yeah. Um yeah, I mean fortunately the they have some pretty good docs and I was able to figure out most of most of these things myself. Um but yeah, they've been helpful and responsive. So it's great. Okay, great. Okay, very good news.

Thanks for sharing. Um okay, any other updates? Yes. So on the conscious spec side, I'm working on conscious spec tests. I've added basic unit tests and there were some missing pieces in the spec. So that's what I'm currently working on at the moment. After completing the spec, I can resume adding bunch of tests and the fixtures will also provide enclosure list as a file so that CL clients can consume it.

Uh timeline wise, Justin and I aim to ship it in the next consensus spec release if it's possible, which is in two weeks. Okay, sounds good. Uh great. Okay. So, it's it's awesome because you guys are like sort of like working in parallel on both the consensus execution side of things for tests which is really cool. Um yeah, let me know if or let everyone know I guess if you need input on ideas or things to test uh at any point. Um I feel like there are quite a lot of scenarios we can actually sort of play around with on both sides. Um but uh

maybe yeah I know we are not necessarily there yet but uh would be nice to also chat about this and then does anyone else have uh something to share. Okay. If not, yeah.

Um, yeah. So, I just remember that there was a feedback that there was a discrepancy between the overview picture of the EIP and the text below. And it'd be nice if you could align them. So maybe um yeah, Joe Cham, do you want to talk about it more? Uh yeah, it was just something I noticed when when reading the the EIP. So I think if you if the text and the picture matches, then it is also much easier to understand because now it it looks um yeah a bit contradicting when you read read the Okay. Yeah, I remember seeing that in

the discussion for sure. I can I can take a look very soon. Let me just make a note of it. But uh yeah, no, that's a that's a good good point. Uh we definitely look into this. Thanks. Then Mercy, you want to talk about what you shared? Yeah. Um I working on the front end of the transaction visualizer. It's still empty though, but uh I was hoping to try and populate it and see what the the transactions and and how it's going to actually look like, but this is where I'm at at the front end currently,

but the back end is mostly ready. Yeah. Nice. Okay. Super cool. Thanks. Uh nice. And then let me check. I remember wanted to ask a client team that was very very close to Oh yeah, I think it was Lighthouse. I remember Lighthouse being very close to interrupt and then sort of like not hearing from you guys. Do we have someone from Lighthouse here?

No. Okay. Um, yeah, we'll we'll just follow up with them later, I guess. But, uh, great. Okay. Is there anything else? Okay, cool. Uh, then I think we can uh end this. Thanks a lot for joining and participating and see you in two weeks.

Thank you. Heat. Heat. What's up?

Heat. [Applause]