FOCIL Breakout #5

Transcript

all right so thank you for attending fosil breakout five uh we have roughly six agenda um firstly there was a discussion on solo stakers and censorship resistance on Twitter we want to scale etherum but without sacrificing verifiability and censorship resistance this is where solos takers kick in having a diverse set of participants each with a different interest would be the powerful way to achieve this especially when it comes to censorship resistance but today censorship resistance on ethereum currently relies on solo stakers who locally build blocks

however they have to forgo the profits they could have earned if they used map boost but with fossil solo sakers no longer need to choose either of profits and censorship resistance they can still signal what should be included in a block without sacrificing their revenue by using BPS for example so fossil opens opens the door for better scaling as it allows us to explore more into PBS or APS as well as it makes solo sters relatively bigger in the censorship resistance Service uh there should be a link to the

uh Twitter in the in the GitHub so please take a look if you are more interested and we also covered the comparability between delayed execution and puzle there have been different designs proposed for delayed execution including delayed State Road inclusion delayed execution using static static validation and Skip transactions and payload block separation the idea is to remove the transaction execution from the critical path and delay it which could help increase the blockage limit Franchesco suggests the way to

make fossil comparable with delayed execution the one that introduced SK transactions uh so M what mainly it does is it enables sort of static iil validation using bitfield we add a bitfield over the I committee to a block and and a proposer marks bits corresponding to the ILS that it took into consideration when building a block and during the static validation phase a testers check if the is specified in the bitfield is a superet of their collected ILS they don't check if all IL transactions transactions are included

they just care about the bit build exclusively and in the next slot a proposer valid whether the head block contains all valid transactions in the IL specified by the bitfield and it extends the head block if it does or extends the parent otherwise a testers follow the same process to to decide whether to vote for the head block or the parent um the idea is similar to how we make bossle comparable with EPB so let's take a look into the Franchesco hackmd for more

information and next up is there was a discussion about ilil building rules proposed by Mark uh it was about optimizing for throughput so but be before we make any conclusion I think it would be great if we can have an open discussion so Mark uh could you elaborate it is Mark here yeah I'm here I can speak a bit about this um so kind of what uh started me uh thinking about this um Is So currently we don't H specify the rules for um inclusion this building uh

so different client implementations are able to just come up with their own rules um and the idea here is that you know clients will come up with quite a diverse set of rules for building an inclusion list and this could help with um censorship resistance um so I think this can be a good thing um and we should kind of leave it unspecified but I think there are also some potential dangers there so I think in the worst case we might kind of see a situation where a lot of um clients Implement a very similar set of rules where they uh um score transactions like just decide which ones they want to include in a very similar

way for example they might all just um order by priority fee um and if something like that happens so everyone's using the same set of rules which are completely deterministic then all of the um 16 different people who are creating inclusion lists would create the same inclusion list right um and so ultimately we're going to take the union of all of these transactions but you know the union of 16 different identical inclusion list is going to be one um 8 kilobyte inclusion list um so sorry to specify that so every every individual's inclusion list is 8 kilobytes and we combine them all if they're all the same it will be 8 kilobytes in the end whereas if they all

had kind of different inclusion list with no overlap then we could potentially get up to 128 um kilobits kilobytes sorry um so kind of what I'm saying is I I think that we should um attempt to kind of um encourage client implementations to do things in a way where we don't have too much overlap I think we should still leave it kind of unspecified so they can experiment with different ways of doing things but by having less overlap between inclusion lists we can ultimately have a much larger inclusion list which means that we can kind of just have uh higher bandwidth of censorship resistance uh because in my opinion just having one 8

kilobyte inclusion list isn't really sufficient like if there's a mass x something like that then we need more than 8 kilobytes to um to kind of force include all of those transactions um so that's the background and and sort of what I've proposed is kind of few different things that client implementations kind of could consider one of those is using some Randomness so having just some non-determinism can kind of mix things up a bit and reduce the chance that we're going to have all sort of very overlapping um inclusion lists and the other thing that I suggested is with this Randomness having some bias um so by bias I mean that um

an implementation will be slightly more likely to select some transactions over other transactions um and the way this could be done is basically want to do this so that each one is biased in a slightly different way so the overall there's going to be less overlap so the way that I've proposed to do this is we have these um 16 different members of the I committee um so for these 16 different members we can assign them all their own uh unique ID right so we can call these zero through F the different I committee members um and what I'm saying is we could bias it so that if your Committee Member a then if you see a transaction in the mempo with a hash that starts with a you would be slightly more likely

to include that transaction um and in this way we could uh kind of significantly reduced the amount of um overlap um between inclusion LS um so any thoughts on that um yeah I can maybe add some thoughts like this is something that I have been thinking for a while as well I think my general like um feedback to this is that I do want to see like no I definitely agree I I think most of us will all agree on basically giving a set of recommendations on E clients to follow but then I do know that I think

that's kind of missing in the EIP today that there's no set of recommendations people it's kind of vague in a way but it would be nice to have a list of items that people can follow for example like priority fees um random order or um sore by how long transactions has been the M sore by how many times transaction has been re and stuff like that I think the question is that do we want some sort of random rule in and then and then also having a random rule but also add some implementation complexity for example adding the committee index passing through engine API I think I'm I I I think I probably want to wait on adding

changing the engine API for this because we don't know if we actually need it yeah I think that's actually one implementation complexity that's like kind of like I I I don't want to having to do that but at the end having to take it out later realize we don't need it in a way right I think maybe we need some like basically maybe some like study on this topic we can just look at today's Mano and then give like two to three uh I building algorithm and just to see how efficient it is without some sort of Random order subset type of algorithm and then if it's not sufficient then we can maybe go back and say okay well now we need to fix that uh one way to fix

this is like you said by adding some uh index field in the engine API so we get better Randomness but I think without some sort of study like that maybe we should hold up on changing the engine API but yeah I definitely agree with you the EIP should be more clear on um giving some set of recommendations that people can follow that just my minor feedback yeah that makes sense I mean in my opinion like it it seems like quite a minimal change um to to just pass in this additional argument um and then you know it just gives clients then the option of what they want to do with it um so yeah

again I'm not um maybe before I was present it is like this is like a specific algorithm but I really think it should it can be a good thing to leave unspecified um but yeah just if we kind of so I've made a PR to the EIP and it kind of you know uh lists some of these things that you might want to consider like time spending the mle ETC um and I think that you know if we just add this small argument then that would give clients the option to use this if they want to um and also this is generally a thing where even though it's not like imposing a certain set of rules you do need to kind of coordinate some kind of standard before right like you know assign these IDs and agree that you're going to um

you know have this mapping of uh IDs to which uh different transactions right so it's kind of something where it makes sense to at least mention it in the IP so that everyone does it in the same way and the different implementations will work together do we have any more ideas or feedback on this um I can send to the chat the um the PR um it's already linked in the uh GitHub but if anyone has any uh feedback they could they could leave it um there on the eth magician thre as well all right so for now I think we can conclude that

uh Mark's proposal would be considered as one of the solutions when we want to prioritize throughput but we think we need more study on that topic before changing engine API and in the meantime we can modify EIP to have some recommendations to follow and yes uh thank you for the sharing the link to the pr uh that brings us to the next agenda and Mark wanted to discuss his PR and get some feedback so do you w to talk about it more

Mark uh yeah so yeah so I've made two PRS basically so one is this kind of um recommendation for an actual like change to you know add this stuff and the other one is just kind of uh fixing a few things that seem um that could be clarified or or not completely accurate um so to the EIP I added some of the um engine API changes that um Jun had written up somewhere else just to put it all in one place place um just clarified a few few things but I think the most important thing I saw was that in the EIP in many places it says that if the payload doesn't satisfy the inclusion list then it's um invalid and it says

this in quite a few different places and also kind of uh says things about the implementation based on this uh whereas from kind of speaking to ter I've realized like that's not exactly the case so the payload could still actually be considered valid if it doesn't um uh if it doesn't satisfy the um inclusion list but the CL will try to reor so yeah the biggest change I made was kind of um uh uh writing this up um and kind of changing all all of this so yeah if anyone could also uh review that that would be good because this does make quite a big difference in the actual um implementation on the um

outside right so please take a look into the pr and give some feedback and mark thank you for your feedback on the G implementation no problem yeah okay so yeah I think we can move on to next agenda um we have an issue in the interrupt between prison and load store uh we are suffering from State Route mismatch and invalid signature because of the use of wrong Fork domain can we talk about how this issue is being handled I have not looked into the issue unfortunately I've been busy with Petra

stuff but yeah I will probably start looking at it once uh Petra becomes more stable but yeah I wonder if anyone else has any input on this right no worries um do we have anyone from lotar right um yeah so basically it's probably just what I uh mentioned in the Discord channel it's basically uh prism uh wasn't setting the correct Fork version in the beon state and that yields to one of the causes uh for inal Signature which is rejected by Lar

um and it looks like I don't know what Terrence did and uh if he fixed this issue uh yet or not uh but last night I ran the latest version of prism and it still uh has this inval signature issue maybe it's a different CA uh than before but I'm not sure yet so I still need to go through it right so after we somehow have this issue fixed then uh we will likely have the first inro between CL and cl um yes so I think now we covered the most of agenda already um last but not least um we can do status updates I

guess I can go first I I've gave a bossel talk at consens Hong Kong I wanted to give an Eli five of fosil why we want to have in col list how it works basically the intuitions behind incal list let me share the URL to the recording in the chat and I also fixed G to support the transition from Electra to Fu then fossil fork and that's all from my end um not much from my end I'm mostly focusing on Petra so once Petra is in a good State I will go back to Fossil um um haven't been uh sorry

um uh haven't been feeling well since the better part of last week so I haven't been able to make too much progress uh on the Wrath implementation um but yeah uh turning a corner on that and yeah hoping to get back to it and for the uh NE mind implementation I can't report too much um progress I mean I was hoping to kind of start testing interop with prism uh but then I kind of realized some of these things with a spec that um it that I needed to end up changing the implementation um but yeah I mean hopefully now that I've kind of gone through and and made these spec changes

it should be a little bit more um streamlined for other client teams yeah on the low star side uh last week I rebased the fal implementation uh on fulu uh previously it was on Electra uh just so that it could play it could it can play nicely with prism more um but yeah but moving forward uh I think we still want to add the flexibility uh so that uh we can have fulu activation and the EIP 7805 Fork activation in the same Epoch uh so low star but other than that uh it's still pretty minor uh there's

not much of code change on lar side mostly just testing um on te side last week I I run a first interrup uh with few take notes um we are creating and Publishing inclusion lists there are still some missing steps on the um Fork Choice side but I think we're ready to to to run some test some interrupts with other clients that's my goal hopefully I will try to do that this week do you mean in interrupt with e or CL can you can you repeat I wonder do you mean what do you mean by interrupt like do you mean

interrupt with Y or other cons no actually I was running just two nodes running te and some stop e that generates just some random uh inclusion list oh I see oh do we have anyone from Lighthouse um I guess Lighthouse shared their updates last last time I guess no um so that's all for this FAL breakout does anyone want to share more updates or have anything more to discuss yeah hello um updates from me uh

I built some draft metrics on on on Prison but uh yeah stuck a little bit with merging new updates and uh yeah um probably for the next session I will already show dashboard I hope it will be ready next time very great um yeah anyone else all right then I think that's it for today um thank you for your attending have a great rest of your day and let's conven after two weeks