FOCIL in Lighthouse

Transcript

[music] [music] guidance of Ethan, our great mentor uh from the lighthouse team. So yeah, let's get started with a bit of context here. So basically, Glamsterdam enshrines the builder, but that doesn't guarantee that your transaction would be included there. In fact, if we look at the numbers, um it got better. um around 16% of the blocks are now censored but there's no in protocol mechanism to guarantee that this will go to zero. So we worked on moving this to zero with fossil. So a quick reminder uh on the consensus layer side introduces an

inclusion list committee of 16 validators each validator uh pushing an inclusion list um on the network. Basically the builder on their beads has to respect that and then when the payload is revealed if your transaction is not there then the payload wouldn't be satisfied. It will be orphaned and then the next block will be uh built on an empty parent. So that's mostly it on on in a nutshell. Of course we thought about how to bring this in lighthouse.

So we started with a plan uh four phases. Uh the first phase was uh basically foundation adding the necessary types and boilerplate helpers to get the inclusion list committee uh members and also inclusion list signature verification and then we split in two. Uh my part was focusing on producing inclusion list and making sure the proposer are proposing blocks that are inclusion list compliant. And Rahul uh was responsible for ingesting the inclusion list and enforcing them at the for choice. Then we focused on testing and interop. So let's dive deeper into this. First milestone for me was

figuring out how to produce inclusion list. So uh the flow is basically figuring out how to leverage the interaction between the validator client and the beacon node especially beacon API to uh to do this. On the beacon API side following the spec I added uh three new endpoints. One for fetching the inclusion list committee duties um for an epoch with a dependent route. Then uh the actual inclusion list for a particular slot uh integrating with the EL and checking the uh payload against uh some gossip limits and then um the third uh actually publishing the signed

inclusion list on the validator client side. It had uh there are two big parts. One part is updating the existing duty service which basically each slot refreshes the inclusion list duties and caches them by epoch and dependent route. Uh so that when a rework happens it's really easy and efficient to um fetch uh the the duties for for an epoch. And then a new addition was basically adding a new inclusion list service. This was responsible for um basically it was waking up 1 second before the inclusion list deadline and this is also a trade-off. We chose a

fixed time later in the slot to make sure that we have nonredundant transactions in the meool and we're still iterating through this and uh fetching the inclusion lists then signing those and then publish uh publish them through the beacon API. The second bit part of my work was um updating uh the proposal of the block for doing so like the proposal gets external bids. So basically um it has a uh has added this new inclusion list bids field uh which are coming through gossip um uh at the beacon node level

and we had to update the check there. So we make sure that the new bids are inclusive with regards to the view of the inclusion list received by the proposer. If the bid is not inclusive, we ignore it. If it is inclusive, then we cach the uh highest value bid for each slot and and parent block. So we have this gossip bids. We have the direct bids that we they come from the configured builders. uh they also have checks uh that um basically uh do the same logic apply the same logic to to the bits and then we have the local bid building and this flow um I also updated

this flow integrating the engine for choice updated V5 uh which now takes the inclusion list for um the slot before uh proposing uh so that we make sure that the payload um for uh the block is respecting the inclusion list. So yeah with uh with this um basically we have three bits we pick the best as we were already doing and this is also the blog proposal part. So I'm going to give the mic to Rahul to detail the ingestion and enforcement side.

>> Yeah. Uh thank you Christian. So Christian uh showed us how IS are created and uh how proposers use them. Now I'll go over my part of the implementation which basically spans over uh everything from when an IL reaches a lighthouse node starting from let's say gossip uh to verification uh storage and then enforcement. So yeah uh first we have uh every single aisle goes through checks uh in spec order. Uh we have the uh signature check at the very last because it's the most expensive one. uh is have their own queue uh which is processed right after the payload assess stations uh because folks choice depends on them. Um uh a rule that matters a lot is timeliness. So an IL is counted as

timely if it's uh received uh like before the deadline which is 9 seconds into the slot right now as per the current spec. Uh and all of the are timestamped upon arrival. So like you know if the queue is busy uh they won't be counted as late and uh also like if a validator like you know proposes a second different I uh it like you know we we will still forward it to so that the network learns that that they have equivocated uh but anything after that is dropped. Uh next is the storage. So all of the like you know verified uh issu are now like you know sent to the store uh keyed by slot independent route. Um we keep uh the iss one slot longer than what the

spec requires us to because uh sometimes payload arrives late and they still have to be you know check they still have to be checked against it. Um and also like you know um if if an if if an has been like you know uh sent by an evaluator in the same slot and dependent route uh we flag them as equators and anything after that is dropped also uh who reads the store. There are basically three major parts of lighthouse that reads the store. Enforcement and bit cursive check are the ones which only reads the timely whereas uh the block building uh reads all of them including the late ones and also like you know if a peer has missed

an IL it can fetch it over the inclusion list by indices. Uh next is the enforcement. So when the builder reveals the slot n plus one's payload um we fetch the current like know timely is from the slot n from the store and then send it over to the e uh the e then you know over the new engine payload v6 uh then the e responds back with folks like intrusion is satisfied and then we record it against the folk choice node u if uh if the like you response was false. Uh we like know the payload still remains valid. Uh we just won't build on

top of it anymore. Uh that basically means that uh the next block will build on top of an empty parent. Now let's talk about results. So uh Lighthouse has been participating in the recent devets uh with a funny little happy accident in has a devnet one where we basically had the enforcement stopped. We were assuming that we only like testing the happy parts but turned out we were not. So uh we quickly fixed that in the next dev nets including the uh we included the enforcement and it's running uh perfectly in the uh recent tempetate 2 and three. Here's a picture of the hesitate three where we

can see um all the 16 committee members uh like you know sending their IS lighthouse being three of them uh like lighthouse being three of the nodes and here is one of the lists uh that we can see all it transactions are being included and the list are satisfied and thus the uh payload got extended. We also did a like know local test net uh uh running a local test net of about 80 minutes uh based on the hesit. Uh it included like two lighthouse nodes uh and no start. Um here are some stats. We are still pretty early here like you know this was uh very recent. We just spun it up before Defcon. We are still you know continuously working on uh more

metrics and monitoring for lighthouse. Now what comes next? Uh we definitely aim towards Hagota um uh we want to you know continue contributing to Lighthouse of course and Fossil and all of these spec changes um interestingly after right after Defcon we'll be having Hakodet Zero where Fossil will be meeting frames so that'll be pretty interesting to see uh we also want to formally verify the store as suggested by Eton so that'll be pretty fun and yeah basically just you know keep learning keep building and keep contributing to Ethereum Uh yeah, last but not the least, we really want to thank Mario for, you

know, organizing this wonderful cohort of AP7. A big thanks to Eon for mentoring us all throughout the cohort and guiding us. A thank big thanks to the Lighthouse team for all the wonderful reviews and feedback that was really helpful. And uh yeah, that was it from our side. Thank you so much for listening. Uh we'd love to hear any questions that you might have. Yeah. Do we have any questions, folks? Yeah, Andre, go for it. I'm next to the speaker here. Uh, so, uh, what are your plans for formal verification?

What are your plans for formal verification? >> Formal verification. Well, this is an ongoing plan. We we just had the brief chat and we want to basically use ANS and uh uh somehow um use this kind of workflow to be able to formally verify it uh verify it but we didn't dive into the details yet. So we want to plan this and make sure that we properly do it. So that's one of the plan.

>> Yeah, you should use Ethereum. I just made proofs of fossil. >> Um I'm Can you repeat? Can I repeat? uh in Ethereum. I just made proofs for fossil. I will present >> uh >> yeah yeah okay okay I'm curious >> we are planning on using Ethereum but also we have things like the IL is store cache which aren't necessarily speced out but there's some invariants there that we want to prove as well and uh also I guess I just want to say thanks to both of you uh we wouldn't have been as far along with development without you guys. Um all the success >> [music]