FOCIL Breakout #4

Transcript

Should I just like press start? Recording in progress. All right. Yeah. Thanks everyone for coming to false breakout session number four. Uh let's see. So I I put some items on the agenda, but as always like uh feel free to also jump in and ask questions as we go. Um I want to start by sharing a few slides. It's going to be very brief I promise but uh there were some cool things happening at least I think

so. [Music] Can people see my screen? I can't can't really see the check. Oh, there. Okay, perfect. Uh, okay. So yeah, I want to just basically first share a few research updates. Um it's going to be very short but uh yeah the first one is

um we I mean we yeah I mentioned in in this call quite a few times that um we were working on what the future of postul can be and um and I mean in it includes like reward mechanisms and fees but it also includes maybe how fossil can work for blobs. and privacy which I think is like very exciting and very very important. So last week uh with George and Benedict we published a post uh called ZK for um basically it's like a protocol um that allows you to privately elect

includers and then let them sign and publish inclusion lists by proving they were valid includers but without actually re revealing their identity. who they are. And yeah, I think it's very very valuable um because it means validators could just participate in improving Ethereum censorship resistance without actually being linked to specific transactions and and you know like these transactions can be censored for for any reason economic or regulatory. But like it's it's very nice I think for people to be able to participate without like knowing they can be held accountable for actually

including these transactions in in their lists uh and then later in Ethereum blocks. So I think that's very um promising as a research direction. I think still like obviously like a research post but um we want to make progress on this because um and there are like two basically two ways two that you could like potentially participate right now. One is the the ongoing open academics grants round. Uh so there is one every year. Uh and so if you have like more like theoretical I guess expertise on

linkable ring signatures um and you can help us like design a scheme that is very tailored to to R LRs's so linkable ring signatures um please either like reach out or directly apply but maybe even better if you if you reach out so we can know you're interested and maybe we can discuss. Um and then the second part of it is uh people that are more like I guess applied cryptographers. If you think you can help um actually like making a prototype uh for ZK also uh for example for like the the generic SN version that would be

like very very useful too. So again like if you know anyone or if you are like a cryptographer interested in participating just uh please reach out to us. Um, I I really want to push this. Like there are like some tradeoffs and and limitations and like things we still need to figure out. Like it's not like a done deal and like cryptography is always quite tricky uh to either figure out or implement. But uh but um I think it will be super valuable like I I do feel like it's like privacy for includers has to be part of the endgame for for sensor resistance. So um if you want to contribute to that uh please do.

Um I cannot see the chat so I'll just like keep going and then like you guys stop me or raise your hand if you want to intervene or if you have questions. Uh the other thing yeah I I published was a small note on false meets delayed execution. So delayed execution has been a topic of interest lately. uh there was a post and then also specs that were worked on by Tony and and Franchesco and so I I sort of like digged into it a bit and wanted to understand how that will fit with false

and yeah the TLDDR is like it's it's not actually easy. Uh there are like some kind of inherent weird incompatibilities that we would need to figure out because uh yeah the core principle of delayed execution is that you delay or like do it asynchronously at least like um execution and like some of the tests validators have to do before a testing to a block. You delay some of these uh after they they vote. So they can basically do a static validation. So quick checks uh and then um vote and then and then like as asynchronously

like the execution the actual execution of transaction is done um and this is great because like actually allows uh efficiency gains and it's I mean it's it's good for scaling but there's kind of an inherent incompatibility because sometimes with fossil uh if you read the EIP closely there is like some some part. Um, and basically if the proposer's payload doesn't include some IL transactions, whatters have to do is like make sure those transactions were excluded from the payload because they were invalid. Um, and yeah, in some cases they need to execute transactions

to actually make sure uh the transactions were invalid. um especially with like 7702 and account abstraction and like you can like withdraw balance balance for from like from an account. So you you sort of have to like run all uh and like execute all the transactions to really know whether like the transaction was uh valid or not. And obviously this is directly in conflict with like the delayed execution proposal. Um so yeah so I I proposed some solutions obviously like uh delayation is also quite a new proposal so we don't even know like what's going happen there but um it was I think worth checking out and

like it's always interesting to see like the interaction between fossil and other proposals. So yeah if you have ideas on when to check check it out it's it's there too. Uh and then yeah, Terren also published a note uh on interactions between forceful and EPBS. Uh and uh I yeah I just highlighted like screenshotted one section here but I will let Terren speak to it if you want to. Sure. Thanks. So I guess like to give slightly more background right delay execution I think right now it's becoming like a loaded term like there are different flavors of delay execution I think at the minimum what the

currently proposal I've seen mostly is that just have the proposer um include a pre-state route instead of the post route so by that as a proposer builder you get more time so this works really well with like for example zk Right? But this doesn't really help as a node that is verifying the chain because as a node as a tester you still don't get the benefit of delay execution. So because of that you can take another level and this is where like there I think there are two solutions I've seen.

The first one is with ETBS which uh changes the structure of the block. So now the block instead of containing the execution stuff the block only contains the consensus stuff and then the execution stuff is becoming a separate object. So you have this some sort of pipelining. The first half of the flot is consensus the second half of the uh slot is execution basically that's one that's one solution. And the second solution is like what Franchesco and Tony proposed. Basically the block instead of including the current state affair of everything you just include the past state affair. So that just means it's not really just the pre-state

root you also includes like the pre-receed route the pre um the basically the basically the pre-b bloom uh tree stuff and more right so that this also changes the entire paradigm. So I think there are yeah so there are two solutions. I think my interest is mostly on EPBS that's what I've been working on for the last few uh years. So I think with EPBS and fossil there are benefits and there are also incompatibility right because of the inherent nature of EPBS that the delay is pipeline sorry not delay the execution is pipeline because of this you actually don't have the same problem as the Franchesco and Tony proposal

because you still have about 9 seconds to verify the IIL are satisfied with that situation payload you just do that at the second half of the slot. basically but the but the downside with that is that because of a as future are revealed at the six second of the slot. This doesn't play nicely with the inclusion this committee member because currently inclusion committee member you are doing your task at about 8 seconds at at the deadline. So now you you go from today the block is review at two seconds versus the payload review at six seconds. you you lose about like 4 seconds there. So yeah, so I mean there are no like basically the best solution

out there. I think everything we do here is going to be a tradeoff. You either just say okay well as an inclusions committee you're going to get less time in EPBS and maybe that is okay or you change it to something that's more like uh next slot scheme meaning that slot ends IIL is satisfied on slot N plus one and then you have this skip slot in the middle something. So I I don't know what a good solution is. I mean I just started looking at it like a few days ago but yeah um yeah I am curious for feedback. So yeah, please reach out if you guys are interested in this topic.

Great. Yeah, thanks a lot. It feels like with the EPVS as you mentioned it's a more of a of a trade-off of of timings and with like the other version of delayed execution I talked about it's it's more about like who do you attribute the fold to if there is an invalid transaction like even if it's skipped like some someone has to pay for it otherwise it's like free DA free data availability so so yeah I think the the the spectrum of tradeoff like we are just starting to scratch scratch the surface. But uh obviously like when you include changes that are like as big as like delaying the execution or like changing the structure of the slot, you

you get into like a lot of different uh questions, let's say. Uh okay. And then there's my last slide, not last but not least. Um it looks very simple, but I think it's it's actually very nice. Uh so Ji Hun and I worked on like a very simple way to track the implementation progress on for each client uh CLMDL. Um and so yeah it's it's very simple but like basically we will keep this up to date so everyone can just like go on midforall.

So something we have shared before and check out clients progress there. Um yeah, I think it's a great way to basically quickly have an intuition about where where things are at, like um what where our like clients are at. And um yeah, if you So that means also like that you do have to reach out to us if we don't reach out to you if you kind of sort of like make progress or like achieve one of the milestones we defined here. So we can actually keep it keep keep it up to date. Um but yeah so if you are a client and like the current graph is not reflecting where you are at

in terms of progress uh which shouldn't be the case but like let's see uh then please uh reach out to us so we can keep this up to date and when people ask like where is at in terms of implementation we can just like point them out to this resource. Uh yeah and I think that's it for the slides. Any anything in the chats? Okay. Mostly sharing resources. Nice. Okay. So maybe now we can actually move to implementation updates and and progress. Uh I was looking at the the inclusion this channel on discord which

is also where most of the things happen. Um, and but maybe I I'll let people that actually are like client devs or work on it right now like give updates if you have some. Okay, maybe I will prompt it a bit more. Uh I see Mark is in the call and and you you did post like uh some progress that Nethermine made and I I don't think like Nethermind has shared updates just yet.

So maybe if you can say a few words about where you guys are at. Hi. Um yeah, so I've worked on prototyping and implementation. Um it's passing all the tests. Um, and I did share an image in the in the chat, but I can I can share that again um if anyone needs it. But we're just starting to um look into trying out Interop with Prism, but I haven't tried that out yet. Great. Yeah, thanks. And I know Loadar has made some progress. M I know Matthew is not here today but like if anyone wants to share where you guys are at because it seems like it's progressing

quite well on your end. Yeah. So two weeks ago we have finished all the basic implementation of it and ever since we just uh reviewed the code internally and try to interrupt with uh G uh cause some uh engine API issue on the G side and I think June has fixed all of them. So now for uh low star only defets that run locally uh they are progressing fine and I can see like uh inclusion list is bring uh is being created is being broadcasted and I can see the proposer is uh obeying

the inclusion list and the chain is finalizing. Uh I think the current step right now is trying to interrupt with uh Prism, but there's still a state root mismatch that I still need more time to debug. Okay. Yeah, that's awesome. So if I'm not mistaken that would be the first like CL CL interrupt because now we have obviously interrupt between like G and Prism or like ref and lighthouse but like it would be like the first time loadar and prism actually like interrupt together right yeah so I can say right now re prism is

rejecting lowar's block and lowar is rejecting prism's blog uh because of the right Yeah. Yeah. No, right. But like I mean like your guys are working on like making the CLCl interrupt work. Uh which is very very exciting. Nice. Uh cool. Uh anyone? Yeah. I was wondering I actually like didn't ask you that before but like Terren do you have updates on like maybe testing? I know you were like looking at different cases.

Um I think we have tested the happy case and we found a issue with E um with G. they were um responding with um instead of base hacks they were responding base stat 64 um inclusion this transaction transactions bytes and other than that I have tested some of the reord stuff to make sure that as a proposer we can um reord um block that doesn't satisfy inclusion disc so we we did that and then but again I've changed my implementation a few times just because I wasn't happy with the previous one.

So, we need to do some more testing on that. But yeah, not so much about not so much progress for me for the last week because I've been mostly on the Petra stuff. But yeah, uh once the Petra test net launches, I will be more into testing stuff. Okay. Yeah. Awesome. That makes sense. Um, yeah, I remember you also had a doc with like listing a list of potential tests we we could use and we could probably like use that and revisit it to test all the possible edge cases that might happen and see whether that all works out with the timings we have currently. Uh, and yeah, any other updates from other

clients? Uh so we had oh yeah another update I actually didn't talk about it we had a a podcast on for with puja for people IP uh I think we it went good uh and we had some people attending that weren't like really uh working on fossil but like that seemed that seem interested to to contribute now. Uh so this is exciting too. Let's let's see how that goes. And yeah, I'm I was wondering how if like things have moved for you, Jacob, or like Lighthouse, right?

Yeah. Um so got at least the happy case working for uh Wrath and Loadar and then independently W and Prism. However, trying to run one ref load store node and one ref prism node um there were some issues um that I didn't get to investigate, but it sounds like there might be some state route issue.

Um and yeah, now working on uh different test cases to try and orphan blocks based on uh blocks not complying with the inclusion list. um and be the first one there. Um but I do see that Dan from Rat is on the call. So I just wanted to ask if the RAT team is looking at like dedicating their own capacity to working on fossil or Yeah.

Uh yeah, I mean we're uh just looking into it, but um yeah, we can we can help with with stuff. So like if there's a branch um or something we can or if there there's like bugs anything just uh let us know. Cool. Yeah, I can share the break. Um but yeah, we're happy to like get things upstream if that makes things easier as well. Okay. Uh yeah, not sure if it makes things easier, but um we can talk about it offline. Um but yeah, um other than that, not too

much. Uh I think between now and the next call I'll just be working on yeah trying to break things and making sure that the um yeah adversarial or misbehavior cases uh fail as they should. But that's also nice. Yeah. Yeah. That I mean that's already quite uh quite good to be honest. And yeah, if Re can also help out, that would be even even better for sure. Uh, is there maybe somewhere we could like list all the all of the tests like

people have tried so we like sort of like at least keep it in mind because I mean there are going to be quite a lot and I don't want like uh anyone to forget about like some cases uh along the way. So yeah, maybe I'll think about it too and we can talk about it offline, but like maybe I keep a list of like all the problems that were were tested and and sort of like checked would be would be useful. Yeah, I know Terren had hack MD, but I think it was highle tle test cases. I don't know if there's something more uh current or if that's still what's

being used, but I'm aware of that one. Yeah. Yeah. Yeah. Yeah. No, I I Yeah, we we could either like use that or but I was wondering like ah I mean you know you have tested this edge case with like this combination of clients and it it passes like would be probably useful to to know where things are at there. So, I I I might like prepare something just to to check this out. But, uh, thanks. And then, um, I see Ethan, I think, from Lighthouse.

Yeah. Yeah. Oh, Lighthouse wise, uh, this week I've been spending time interoping with GU. Um, just working through like a few small bugs. Um, but hopefully by the end of the week we have something working on a cryptosis test net. Um and then we can hopefully join Prisma loadar and try and interoping with them. Yeah, that goes. Okay, awesome. Yeah. Okay, that's great. Nice. Okay, so we do have a really good progress. Um, yeah, I wanted to ask about Dora the Explorer cuz I saw some conversations and I'm not sure exactly if there is a blocker or like or what we can do to to make uh things easier with the with the

explorer. I think the issue is um in low star because we have already defined like a new fork version for fossil and Dora explorer doesn't recognize it. So the block the fossil blocks are not showing up on Dora. Um but I'm able to get around this issue by just uh hard coding those fossil block to have the electra fork version then it will show up uh then it will show up. So it's like a minor annoyance uh in terms of like to track the like

the local blockchain how how it's progressing but other than that it's uh it's relatively minor. Okay. Okay. I see. But like so if I understand correctly um if panda apps is like sort of like maintaining dora like could we change things on on there so it actually like recognizes like a um or or is that like not possible? Yep I can have a look at that but uh need further information for that. What block version exactly is used?

Yeah, I think it depends on the beacon API uh spec. I think uh in my beacon API spec PR uh the version is EIP7805. I think the EIP number would actually be nice because we are doing the same for EPBS and yeah other future of Fox. So as long as there's no canonical name assigned to that fork, we just use the EIP number. Okay. Yeah, that's great. So what we used in the beacon API spec was just the EIP and then all lower case and then the number. I think it's already in the event stream the version.

So does uh fossil have uh separate block versions for beacon blocks as well because as far as I understood it's fully built on fulu blocks but might be wrong with that. I don't think right now the block format changed right so but it should be based on electra I guess. So it's basically just the alias for electro blocks right now. Okay. Uh cool. Okay. So maybe follow up

on this. Um thanks. And are there any other blockers or anyone wants to share progress? Yeah, I can give an update from TEU. Uh we've made some good progress. Um we're left with the fork choice changes to implement and some beacon API uh the new beacon APIs to to implement and then we'll be probably ready to interrupt. So yeah, if you could update the the tracker, you can uh put as in started and almost ready for interrupt.

Yeah. Yeah, that's awesome. Okay. Yeah, we'll we'll definitely update it accordingly. Thanks a lot for sharing. Great. And then so no blockers I guess everyone is just progressing nicely. I wanted to get like a maybe a temperature check on like because I know like people are working quite quite a lot on on Perra, which makes sense. Um, and yeah, what's I guess what's a good timing to also reach out to to clients that haven't really started working on it. Um, do we just like keep progressing? I feel like this this is going quite nicely to

be honest and like if you know we have like three four five clients already like working on it I think we're like in a very good position and we can like move forward and and and maybe like people join when they have time. Uh but if anyone has like opinions or or strong thoughts about this uh let me know. Okay. No strong opinions, which is good.

Uh we'll I think we'll just like let people come in when they want to come and when they have bandwidth to work on if if they want to work on it. Um and not push it too hard. Um yeah, if uh anyone wants to say something uh you can. I will give you a few seconds otherwise we can probably like wrap it up early. Yes. Um I just had a quick question about this uh the ZK fossil. Um, so do you think that would be a change to the existing EIP or or it could be done in

like a separate part? So we implement the current EIP and then that's an additional one. Yeah. No, that's a great question. I should have said that it's definitely definitely not like considered to to change like the current for like it's very much research like it's and I would say it's even like it's it's it's early research it's like an idea I think uh would be great if we could implement it in the future but like it uh it's not related at all to including it uh in the current EIP. Uh it's it's a it's more like yeah future plans for what could be a nice end game for Fossil rather than

uh a change that we want to to sort of like push uh as fast as possible. It's not speced out. It's it's not even like yeah um a lot more research work needs to be done before we do anything else. Okay, thanks. That's good. So it's not going to like delay uh potentially including fossil as it is. Yeah. No, not at all. Um, I think like right now at least what I think is like we've been we've settled for a while on on this the current version of Fossil and I don't think like unless like something quite big changes.

Uh there are there haven't been any reasons so far to like really change the current design. Uh and it's it already makes like a very big difference. um like the current version of Fossil like even without privacy without like a reward mechanism like the the Fossil itself like in its current form is like I think very good. So uh so yeah, we haven't like you know we've been talking about fossil for a while and like since we had the EIP out I I don't think like the mechanism itself has really changed and um and I hope it it stays that way because I really want the current for

version to be considered for inclusion um in the the next forks Great. Any other questions? Okay. If not, uh thanks everyone for attending. Um do check out the progress on each client's implementation on on midforol but eith.limo and um see you guys next time.