EPF Day Cannes

Yeah. So I'm um so I got interested into benchmarking JKVMs uh in re and so basically the the project is about um using state transition functions and benchmarking uh various FKVMs and the goal is to iterate through this process to to identify possible roadblocks in the codebase uh which are going yeah so fix them and just move on and also during this process um I should keep in mind that um uh this should be compatible with the bins so far like there are two ZKDMs that have been implemented by the by the team there are some things that have to be to be fixed but mostly it's done one is risk zero and the other one is SP1 and the plan is to extend uh like benchmarking to other safety gems like open VM it's all um so by the way there will be no so uh the green client will be a V client client and currently they also have some vegan implementation but it will be just for for testing. So my current understanding of the thing is that uh so there will be some code that um will have to be proved which goes under the guest directory and the proving is is happening in the host and the way it works is that there is some uh input sent by the host to the guest. Then there is some computation being carried out and then the guest commits the output back to the host and then the host is doing the proving and the validation and then um creates a receipt. Um so the implementation that I've looked in um so how does this happen?

So in the in the host directory we create this exeutor environment so you cannot read it. So this environment gives access to guest in order to read the input that they need and then um they will perform the computation and commit the output to so the the terminology is journal which is the um public part of the output and then uh the receipt that will be created is the manifestation of um the valid execution of the of the guest program and then the last step uh is the action proving which is done in host. So uh the prover is set is set up the proving is happening and also like verification is being uh public. So in in this particular problem there are still a few a few things that are missing in the implementation. Uh one is the uh process execution payload.

Um I discussed a little bit with Unawit who proposed the project. Um The problem here is that uh you have to call the execution payload from an execution client and this would somehow spoil the proof. I didn't manage to re I don't know if this is a priority in if they want to actually resolve this or they are going to leave it blank for the moment. what seems to be a priority is um some optimizations that have not happened and also um currently uh the way that this um example works is that uh each field of the black body is tested one at a time. So you cannot run a proof for the whole um block body and this is also something that has to be implemented in this project.

Um on the logistics is that uh Unawood is actually working on this um so He says that he's going to finish in four or five months. So either one of the fellows or me are going to collaborate in the sense that we're going to speed the load or this is going to be dealt um entirely by him and the rest of us will work on some other uh ZKVM from scratch. Um and so the first step that I think would be very useful for all of us would be to actually scan the uh the whole space of ZQVMs and create some kind of um matrix with some comparisons about an accessibility of the code base and all that um so that we we reach an informed decision on which one to implement and another thing which I find important is collaboration because there have been a lot of people uh stating that they want to work on it. So we have to somehow communicate and distribute the task. So uh there is no overlap from the the team.

Uh what they consider more valuable is that uh we work on a different uh ZKVM implementation because this would be very useful for them. Um and then there is a a possible like one problem that we also discussed is the following. in case something happens in on the side of the ZKVDM there will be no help because maybe people will not be familiar with the code base. So this is something to keep in mind. And yeah the last thing is that there is a pretty similar project proposed by Gandai.

I'm willing to switch if a lot of people want to work on this and you know there are fewer people on the other side so that we we can balance things out. Um yeah I think I think yeah I'm done. Morning everyone. Uh I'm prototype. Uh uh so uh this is my how to say the uh project is from uh the ring team.

Uh so this is one of their four four projects. Uh the ring beacon API. The mentors will be Kobe, Kaden, and one. So uh what is ring? Bream is a beam uh chain client written in rust and uh it goes to be modular contributor friendly uh blazing fast.

So uh uh currently I think it's the most popular uh uh beam client at the moment or although the the beam chain doesn't h have a spec at the moment there are like a lot of contributors a lot of I think uh uh uh participants from this cohort they the they tend to contribute to to to have like more than 38 contributors already and maybe six people already working on the in the team. So, so uh what is beam chain? Because uh ring is a beam uh chain client. So, in short, beam chain is like the next generation of consensus layer of ethereum. Uh so, uh in I think when Justin Drake announced it last year at Devco, they he mentioned like uh nine main features fall into like uh three categories but uh I think a lot of the features can come before even before.

So I think the core features will be these four features faster slot 4 second slots and and three slots finality and chain uh snarification and postquantum signatures. Uh so that's it. So uh actually the they're doing specking at the moment. Uh it won't be ready until maybe uh uh this time next year. So what is RAM team actually working on at the moment because there's no no spect to implement.

So uh at the moment they they focus on on three things. So actually I think they're the only team uh the beam client team trying to implement a fullfeatured uh uh uh beacon chain client at the moment is so uh it's like uh 70 80% done and and they're building uh based on the the consentus spec spec. I think the the reason I asked him why they're do doing it the reason is like uh uh because in in in uh Devco just imagine like uh he wanted to be a like a hard fork instead of a separate chain had to to to merge back. So maybe uh we need to get this client running before the hot fork and it syncs with the the current beacon chain then a certain slot is switched to the like a hot switch to to the beam beam chain. That's that's one possibility but needs to be discussed.

So I think that that's one reason. The other one is the trying to to uh build talent to to find new recruit new developers to attract new developers to this project and uh developers need something to to work on to get famili familiar with Ethereum. So I think that's the second reason. Yeah. uh also they they mentioned that uh through really implementing the the beacon chain features they can do some exper experiments uh within the ZKBM to try to run the current one to to find bottlenecks to yeah that's the the the learning process.

Uh so the second key focus uh of the project is experiment uh with ZQBN Ditri already mentioned uh that the third third reason is like T already mentioned so what I aim to to help there were like uh 60 people in the on the team at the moment uh I think two people from this cohort they they already working on the validator client so that's enough people and uh so uh besides the ZQVM work there are other two tasks beacon beacon API and P2P so what I in for is I want to help on beacon API implementations so uh there are at the moment there are 70 GitHub uh issues uh tagged with beacon API actually uh 42 of them already closed because there a lot of people they they want to help like uh re is quite popular and there are uh 28 open 19 unassigned I tend to start from the unassigned ones some of them are quite hard because I I check the beacon API it's like actually some of the the API endpoint has a lot of uh implementation details it's it's not covered in in the consent spec so I had to like also reference other uh you chain client but just see what they're doing. Uh there might be some missing ones not not listed as issue. I would go go through one by one. Maybe I'll add this once also. I think that's the that's the plan for me.

But uh because there's so many contributors a lot of people may make may come and pick up the issues they finish. So it will like the the whole issue issues might be finished early before this coh work ends. So if I have time for other or there's no issues for me to work on, I explore uh the P2P side and also I tend to learn Zik Zikbm through uh working with uh the Ring team and also interested in in postquantum cryptography. Uh so uh I so on the P2P layer through uh the beam Dave uh from yesterday I felt like because a lot of fundamental change the postquantum uh signature change the signature size will be be different the aggregation communication will be different uh also because the the shorter slot time and the uh uh the three uh slot finality I think there will be a lot of more communications within uh uh peers. So uh I think there will be a lot of work on the P2P side of things.

So maybe I think if we finish the Bacon API, I'll try to dig in on this area. That's all [Applause] you can ask me questions. probably I I cannot answer at the moment, but I try to I mark it down. I'll try to to to answer it in the future. Questions, comments?

Yeah, I'm wondering if like um implementing peer-to-peer beacon API like it's already written in Rust in uh in Lighthouse in uh in uh Grine, right? So how is it different in dream or like why does it need to be clear implemented when we already have two RS implementations or maybe like what is the architectural difference there like what are you aiming for? So uh I think uh I I just started looking into the the code base of lighthouse. uh one one thing I I think I I hadn't spent in enough time to to go through the the code base but one what one I try to like jump from functions to functions just to to see how the how the stack works how the flow how it flows one of the feeling like like uh like I would say like current beam current clients uh become implementation is easier to read like in in Lighthouse use like uh generics heavily like when I try to read the code like I I get lost because it's it's a generic type uh onto another generic type like if I want to really f find what's inside this this type like it's it's quite hard that's only I think that's the only thing I I failed at at the moment but I I think I will find more things yeah but uh about the necessity I I can't say maybe maybe it's not must have but yeah that I think that's the starting point for me. Yeah.

Awesome. Um anything else? Okay. Thank you about to risk translation or as it was called in a project proposals ergon executable resourcing by Marold. I haven't talked to Marold.

So if anything here I'm saying is wrong or bad it's it's my own fault. Yeah. So I I quickly just who am I just you have a sense of who you're talking to. I'm this guy on this card. I'm the bird.

uh and and I like both bit and ethereum. Uh I also like playing CTFs and fuzing and um also do some machine learning research and uh I love the EVM which is like part of the reason I chose this project. Uh and the reason I wanted to join this cohort was to do a bit more applied research and so the direction I wanted to go in was either securing. So I already had a project idea of um doing differential testing between the clients but it seems like I might go more the scaling route which was also some of the another direction to work on like scaling the frame later on. Um so why do this?

So uh some of you has probably seen this post already by Vitalik on magicians where he says oh maybe we should just swap up the instruction set architecture of EVM and move to risk file and the reason for that is that uh the EVM instruction set is kind of hard to prove or it's not necessarily hard to prove it's just inefficient to prove so uh we want to potentially swap the instruction set to make it easier for CKVMs to prove stuff. Um, so should we replace the entire EDM with risk five? Like uh just a few months ago we were talking about EOF and like uh that never happened and like we have the E was in the past and like um may maybe we can do this uh do maybe we can just like transpar it so that we can evaluate this approach and like see how the tooling and stuff like that actually works with um respire. So like translation isn't anything new like there are a lot of a lot of various projects done here like even paradigm had this rmc which does something similar and it takes ev code uh turns it into a vim IR and then into native assembly yours truly has also written like even by code to venom IR transpiler so there's like a lot of a lot of um projects that you can take inspiration from here. Uh so how do we might do this?

So uh as you might be able to see by my beautiful diagram, we kind of want to have a new module on the side. Uh we want to like preserve the existing safe flow of the VM, but we want to have like a bridge over to an installation component that like outsources the CKVM proving. Um yep, separate module. So we probably want to add some execution hooks to like handle the generation of the elf file used by the CK VM. Um and the translation component will be yeah responsible for doing the EVM to risk 5 instruction set mapping handle the fact that EVM uses 256 bit but 5 probably uses 64-bit registers.

Probably want to have constants in the read only data section and pre-ompiles. Uh probably want to use the external column. Yeah. do some pretty specific stuff also. Um, so yeah, the road ahead.

So I'm pretty ignorant a lot of CKVM specifics. I didn't know much about this jumping into it. So still learning about that. Uh, and but the good side of this project is that I kind of also don't need to know that much. I'm kind of like that's kind of outsources outsourced but I also want to learn because else I'm kind of like I don't want to be ignorant to this stuff.

Um, but this project is also kind of big. So also as mentioned in our original project proposal simplifications are allowed. So we are actually able to make a PC uh and then we can remove the simplifications afterwards if if we get a PC out. So like they can require like constants with handing pre-mpiles can be done moreically and stuff like that and also some unknowns like is risk five even the best CKVM or instructions which CKVM do we even want to use? Um and also it's risk in the best instruction set architecture for this like might be on USKVM tomorrow using mix or something.

Um but yeah the main goal of this project is basically just looking at the visibility of all of this and like evaluating if this is is even a approach worth doing. So yeah thank you and yeah posted this in Discord. I know that someone on the uh original standup poll said they were going to work on this but they didn't didn't answer my message. So this is like a call out to whoever I didn't get your name but I know someone said on the standard call they wanted to work on this. So yeah do reach out if you want to chat.

Yeah that's basically okay. Yeah thank you. Uh we have time for questions. It seems like you will spend some time building the compiler for especially for trans. So do you have any um uh plan for referencing any existing like other work or something.

Uh well, I haven't like like most likely we're going to have to leverage or like like the honest answer is that I haven't looked at it so I I don't really have an answer but like it makes sense to like leverage some inter u compiler that can take some IR and then out the risk five. Um so yeah using LVM seems like a reasonable um component to include. Yeah. Any other thoughts, comments, questions? Not a question to you directly but since we're working on this ever since that you know instruction set changed proposal uh the the discussion that has started.

So it it has been argued and from what I know risk file A is not again not the best for Z VMs in itself B it is it is a bit of not a bit of it's it's a totally overkill for what the EVM does right now and what risk five provides so any thoughts on that I mean like I spent a lot of time last week like reading of all the reason not to use risk 5 so or like why and why like there was also also a lot of comments on like Vitalic's original post like why risk why don't why should we not use risk 5 but I'm also being a believer that you should just do stuff and like see if it works or not and like even even if risk 5 turns out to be bad if we if we are solving this using IR we can always like swap out the actual underlying architecture so um I I'm I'm not totally locked to risk five like I I view this as like writing a transportation component which uh should be modular that you can swap out with any architecture or any CKVM. Um, yeah. No, it's great for experimentation. I'd love to follow. Yeah.

Yeah. Awesome. Anything else? Yeah. If not find the bird on Discord.

Thank you. Uh, hi. I'm Jun and I'm from South Korea. I'd like to present the project. uh suggested by present team which is the SSD query language and the microp pros.

So here's a quick brief introduction myself. Uh I'm still an undergraduate studying computer science at Kais in Korea and last semester was very cool. I built my own compiler and OS in ROS 10 C respectively. It was really cool and I also contributing to rim for six months and prior to the APF I have some experience in software engineering. So one of my notable work is build a desktop applications for running a full validator node uh built on the electronjs and also I had some experience in open contributions including the prism rest and lighthouse.

So here's the content and let's get into it. Uh the project introduction. Uh I'd like to introduce the SSC but I'm quite sure that all of you guys are familiar with this concept. So I just want to point out that SSC is a not self-describing scheme. So which means we requires a schema for the serializations the SSC encoded bytes.

So it's a pro it's mostly not a problem in CL because consensus client all has their own knowledge for the what object they pass each other. So it's not mostly a problem. So you can find the SSC.dev that which is a very great starting point for uh this learning testings. So this is these are the projects and those are two projects but the Boston from prison suggested me to uh look up the both project because they are quite entangled with each other.

So uh I'd like to introduce both. The first one is SSDQL which uh query the arbitrary SSD objects. uh so it it may include some features like filtering range or something but uh I would like to build a most basic uh query at first and it was listed by it uh and yeah shout out and yeah I I've talked uh it yesterday about why do we need this so uh I I brought some the reason for why do we need this so as uh for current uses we have some very ad hoc talk implementations for bitcoin API. So especially for the accessing the fields like for electra we have pending deposits for consolidations and we have all like sync committees we have to access through a single API which is very verbose and also there are some APIs for the other clients like debug APIs. So for example in Nimbus we have the sync com uh historical summaries uh we have to fetch sync syn uh no sorry historical summaries from the its own implementation which is very uh I think verbose and also for the future use case uh uh there are uh it is SSC is the core building blocks for building the ethereum in the future including beam or e so I guess it will help a lot to make our life easier and also the second thing is Merkel proof.

So uh it's the term arbitrary is very important in this uh context because we can generate proofs for any uh field in the Merkel tree and it seems like quite helpful for context of the ZKVN because we have to uh verify the untrusted input uh from the post program. So I think that will be great and this is current status of the SSC especially in Prism. uh Prism uses fast SSC which is the goal implementations of the SSSE and mostly use the the code generation auto code generations but uh I found an issue that they will migrate the their own to the their own implementations called methodical SSC so it will be planned and also they are um maintaining the encoding SSC package in their prism repository uh which is useful for the most of encoding And for the status of the projects uh the SSC query language is uh there's lots of things to discuss because uh we don't have spec we don't have a a design documents uh very detailed um things. So there's lots of things to discuss but as I mentioned before there's a great starting point just parsing a path to the specific field. So it will be great starting point and second one is the GMP the marker proofs.

Uh there are some ad hoc implementations for three uh fields of for the light light plans but uh I can't think that uh there are uh I I I work on some draft VR for the generating marker proofs uh for the arbitrary fields that can be directly accessed from the eco state. So that's the process and road map the as I said the true pro two projects can be pipelined. So yeah there's uh uh yeah that can be entangled and also I'm uh happy to discuss and collaborate about this topic because it's quite large and also one thing I'd like to note is we can keep building because all the features can be tested locally with unit tests. So here's some road maps. Uh yeah the uh I'd like to point out two things that the I can start with parsing path uh for the SS query language and also for the marco marco proofs I can uh I should calculate the generalized index of the SSC tree for u generating the proofs.

So there's a road map so you can refer to my slide after the this talk. So that's the conclusion. Um I hope to spec this feature out after the EPF. Uh so it will be nice for implementing any other clients in CL. So I'd like to design a good query language for this.

So this is my just optimistic future for this uh feature. So yeah uh and I'd like to also think about the what is the good design for a core language in terms of the users or the developers. So I'd like to dig into this more and I'd like to introduce two mentors radic and basting from prism and raing radic is here. Yeah and also special shout out to Ethan for design uh for advising the design of the SSQ language. Yeah.

Uh here's my telegram and GitHub so you can follow. I'm happy to chat discuss. Thank you. Any comments, questions, any thoughts? I'm wondering about one little thing that like you mentioned about also proving uh the SS in ZK like we can have the SS pro Merkel which is hashes and hashes and zero knowledge are quite hard to prove so does it work is there any implementation of this like is it because it sounds very inefficient like especially if SSD is supposed to be forward looking beam and so on like whether uh yeah uh in my knowledge uh for the the most common hash function SH 256 and there's some accelerating pre-ompiles for the SH 256.

So it's super uh super efficient if we use the pre-ompiles. So it's uh I think the special designed circuit for the CKV and calculating hash function will be visible for your point. Okay. Yeah. I also talked to from EF recently and he said that the C has improved to a level where SH is only like six times slower than only six times slower.

Yeah. Okay. It may be a valable option. Yeah. Okay.

Fair enough. Like there is also half the number of Okay. Okay. Cool. Cool.

Yeah. Thank you. Thank you. Thank you. Um yeah, that's it.

Thank you. Awesome. I well I'm still in the project selection. I still don't know which one I'm going to do. But this one is one that I think it is going to to be useful from the very beginning because I know that there are some project that would use the solution and this project is called a reason of everything.

the the scope of this project is clearly stated in the project proposal description and is to generate a Merkel proof of arbitrary data data. So for this project we will try to create a miracle proof of the blocks the stakes or any other objects or fields and the current state in the in prison is that for the bitcoin state we only generate a mer of the finalized checkpoints and of the current scene committee and the next committ. And this is due to the the use of this proof. These proofs are I guess they are used because for the checkpoint syncing and also for the lifelines which connect to the s committee and need to verify the the proof. But there are new use cases incoming in the area of taking pools for example where when in this first cases the withdrawal of credential verification when a validator is created by operator that when when the validators are created by operator that you cannot trust you need to make uh to deposit transaction to create the validators.

The first one you do one ether transaction in which the withdrawal withdrawal credential are set and after that when the deposit transaction is processed by the consensus layer re is a need to generate the mer proofs and verify that those withdrawal credential as the are the withdrawal credentials expected the one that belongs to the sticking people not the ones that the operator wants. That would be a front running what is called a front running attack from running attack. There there is also a a solution from Nimbus the the verifying designer in which Nimbus provide the recipient proof in order to detect the if anybody is still in the me. So for this another use case it would be interesting from the to have this proof and also it would be interesting to have a aggregated data in the sense that in the EVM the SH 256 is a costly I don't I don't know It's a costly instruction. So you have to pay like two 2,000 gas units for every hash.

And for this proof, you have to has a lot. You if you want to go from the validator to the validators route, you have to do at least 43 43 hashes and also you have to go to the pickon state and to the root. So if we can do if we can aggregate a medical proof doing multi proofs or even go a bit far beyond this the scope of this project and aggregate data based on on the status of validators for example and sum the balances in order to report the TVL of the project in proises layer or the performance of the validator it would be great but for that we would need zero knowledge we could use and zero knowledge algorithm or the CPVM and so for this project it I think it is the methodology is very straightforward we we need to allow people to choose the anchors and we also need to allow them to choose the fields and the that they want to verify. H after that we will compute in a generic way the generalized indexes. After that compute the pass and build the mer with hashing and in in relation to this I have two goals.

The first one it would be to create the recent production ready code create the generic mer and also from I see myself as a more in the research side. So I would love to learn about the CK foundation and make a prototype of [Music] proving of aggregated data proving like the one the ones I said before the TVL of of a protocol or in the consensus layer or the performance or something and that And any thoughts, any questions? There is this EIP 7916 which can also help reduce the hash because like a lot of these lists they have list that are larger than that than are actually reachable and 916 instead of having these 40 layer trees. Yeah. So maybe that one gets more traction.

I'm S and the project I'm going to work on is called differential LLM. Uh this was suggested by Frederick from the security team. Okay. So the motivation behind the project. So basically what happens during uh during an implementation of EIP?

So there are several client teams that have their own ways of implementing and they make their own design decisions and what might happen with time is that there might be potential attack vectors during the way uh the EIPs are implemented. There can be edge cases which needs to be figured out. Um there can be accidental deviation from the original EIP specs or that can be suboptimal design uh choices. So the idea is what if we have an automated system which can compare the various Ethereum client implementations of an EIP. So imagine as a user which may be a a core developer you give input as EIP member and the clients which you want to compare and then in the output you get report which compares the various EIP implementations.

So for example, if you want to compare how EIP4844 is implemented by uh G and Nethermine. So you can basically give that as an input and ideally get a report as an output uh which compares them as well as looks at them from a security standpoint. So the key features of this system um can be the following way. So at the heart of it will be will there be an agent an AI agent for example autogen agent which is created by Microsoft. So what an agent can do is essentially plan act and summarize.

So one of the key issues with LLM is the fact that the context length is limited. So the top air models or the LLMs can have maybe 100k that are up to maybe 1 million these days. But uh no matter what it will always be limited. So the idea is to have an AI agent that can plan through it. So it focuses on one particular aspect of an EIP.

Then it checks how it is implemented in a particular client and then it maybe writes down uh the final report uh as a note and then it moves on to the next uh part of the EIP and so on. So it's essentially a loop through which it uh it slowly and steadily knows or understands how a particular part of an EIP or several parts of EIP are implemented in a client and then it finally produces a report based on that. So at the heart of it is this AI agent and for to that to that agent the idea is we provide him with uh several knowledge bases. So first of all the knowledge base can be of the EIP itself. So basically EIP doc the specs and the tests.

So these constitute the EIP related knowledge base. There are other two uh relevant knowledge bases. So one of them is the client code itself. So imagine going through a client code. Uh so that is another knowledge base and the third thing is there are pull requests which actually implement a particular.

So three types of knowledge bases and the idea is to arrange these knowledge bases in such a way that those can be exposed via something called MCP servers which are which stand for model context protocol servers. So uh what it is about is essentially allowing an AI agent or even an LM with tools through which it can uh get whatever knowledge base or functionality it wants. So that it we will let the agent decide what it wants rather than us hard coding things. So, so the knowledge base, the agent, uh these are two important aspects and then we have an orchestrator which is based on top of fast API to create an API and this orchestrator uh will also manage the uh autogen agent. So I'm using autogen as a placeholder.

There are several other agents as well for example. So it will remain to be seen which one works best. Um and yeah of course finally there's going to be a front end for the user or a core developer to uh actually uh give input and that front end can all be orchestrated. So that's the overall idea uh of the components. So this is u representation of uh the overall architecture I mentioned.

So that is the yeah the browser which is the front end as an orchestrator which uh lays on top of fast API and also manages the autogen agent and then we are equipping the auto the autogen agent with various uh MCPS. So the MCP can be related to one of the MCPS can be the EIP knowledge base. The other one can be related to tests. Uh that can be uh I'm calling it graph knowledge base which is based on top of the EIP ontology project. So uh that is a project which essentially creates a file which has the which is useful for vector stoages and that file contains the knowledge of several EIPs as well as the keywords uh relevant to Ethereum or the EIP ecosystem in general.

So with those knowledge base as well as uh I'm calling it git MCP servers. So those are relevant to the actual client codebase. uh so for example get client code base or mega mine clan codebase. So all these MCP servers uh are essentially uh the the agent is aware of all these MCP servers and then we give uh an agent a particular task for example like you know compare the implementation of this particular EIP across these and these clients. So then uh the agent will start a loop uh and through that loop it will slowly and steadily move across the various subcomponents of EIP and find out how those are implemented.

So that's the overall idea and uh these knowledge base is uh stored in a u in a graph storage. So for example uh here I'm using this uh PG vector uh which can uh which can store several knowledge base across uh in the form of a vector storage but uh this is also a placeholder. So there are various others like QR or phone um and also there are uh other ways to do similarity search which the MCB servers can use to uh give valuable information to the agent. Uh so this is a rough example workflow. Uh this is like a starting point.

This may change with time. Uh so let's say imagine you are initially giving uh the input in the browser and the browser calls the orchestrator and then uh there will be like the knowledge fetching session for example the knowledge of the uh list of pull requests uh using a G MCP server and the knowledge lookup for the particular EIP for instance let's say 4844. So once the relevant knowledge uh is uh is gotten by the agent then the agent can start its own loop. So the loop uh so the the loop in essentially consists of the following. So the agent can plan then act and then take notes based on uh what it has thought.

So for example one uh small example of the planning and acting is the following. So it can let's say search blob gas price. So it wants to know how the blob gas price is implemented through 844 let's say in bo ethereum. So then it uh it it is the action. Then it uses the uh g mcp server to find the relevant chunks of code which might be actually doing that implementation and then uh it finally uh that might be several code chunks which do that.

So it will go step by step across all of them and finally write its own small note which summarizes how the block gas price is implemented and then it will move on to the next portion of the the uh and finally it will aggregate all of these to produce one single uh comparison report and for let's say two clients there will be two comparison reports and then it will find do the final comparison between the clients. So that's the overall idea here. But this is like you know the current idea. It can change with time as I get more feedback from the actual core developers. Um so yeah a little bit more about the orchestrator and the agent.

So the orchestrator is based on top of fast API. This uh provides the public API and manages the MCP MCP2 containers and it also manages the uh autogen AI agent and u this agent can be initialized as a uh through a prompt which can look similar to this. So the prompt can say you are an EIP an implementation an analyst uh always uh plan act and note. So basically you know hard coding what what are the ways it is supposed to do the uh loop and then u we also need to ask it to only use the listed tools which are the list of MCD servers uh and then stop when you can finally produce the final report. U so this is just an example of the system prompt which can be given to the AI agent and then uh the loop ensures that every step is small relatively small so that we don't hit the uh context length limit of particular element and then come the knowledge bases so uh the EIP knowledge base the test knowledge base as well as the uh graph KBMC which is uh relevant to the ontology project I mentioned before um so it essentially fetches the uh information from the EIP repos, the uh spec tests as well as the ontology and it uh chunks them and stores the embedding in in a vector database and then it exposes certain MCB server methods.

Some examples can be uh the graph query or the knowledge based lookup for the EIP or the you know test fetch which is to fetch from the tests and uh we'll let the agent decide what sort of functionality it needs to call for which portion of the you know subip implementation and then uh then comes the gcb server. So this I'm calling it gives MCD server as a placeholder name. So this implements uh this covers the knowledge base of the repository itself. So let's say go client. Uh we have to have knowledge about the full repository as well as the corresponding pull requests which have implemented this particular.

Um so when it comes to the pull request itself, so GitHub has this graphql API through which we can pull the relevant uh pull requests. then those can be um embedded and that can be a cosign similarity search which you can do to find out how relevant is that particular pull request to our current EIP. So there might be several pull requests which might not be that relevant to our use case. So and maybe let's say if this is a very big EIP then it might have taken maybe 50 or 100 pull requests to actually implement it. So maybe we can do like a post and similarity research to maybe find out top 10 pull requests which are interesting for us and then expose that knowledge through an MCP server.

So that is for the uh for the pull requests. And regarding the full repository itself uh you can we can uh chunk the full repository into uh smaller chunks and eventually convert them into embeddings and store in a vectorzed database and which can be exposed through an MCP server. So some example methods can be you know one method can be relevant to the uh the repo itself the other uh method can be the g div list or another can be like a you know particular vector search. So this is something this is still a work in progress. I have to you know narrow down the exact details.

Uh so yeah the next steps include more research and actually finalizing the approach. Uh I got some very good feedback from the uh nimbus guy. So shout out to them. Uh I will continue this approach of actually building it and uh as well as the same time getting feedback from actual code developers to have better idea about what kind of uh functionality they might actually be needed and uh yeah I'll eventually write a full proposal and road map in the coming one or two weeks and then I'll start executing. So that's it.

[Applause] Any thoughts, questions, comments? Yeah. Sorry. Um, so one question I have is like how do you like because it's right? So hallucination is like a concern.

Do you have any plans on um how to like ground truth output and stuff like that? I mean uh hallucination usually like if you're hitting the context length uh a lot then there are chances of hallucination the if you are staying below that context the chances of hallucination is slightly lower that's my understanding of it so which is why the agent agentic approach makes sense because the agent will only like plan well ahead and you know think in terms of smaller uh subimplementations of the IP for example how the block gas price is implemented so it will ask small questions use the MCP tools to get relevant knowledge, understand it and write a particular note and store that note and then move on to the other uh sub implementation so that the likelihood of reaching that context length will be lower. Uh but there are still chances it will reach the context length and uh yeah when it happens I'll have to figure out how to yeah currently I have no idea how to make it better. What are the criter? Yeah.

Yeah. So there can be multiple ways to look at this comparison. One can be simply how the features are implemented. Uh the other way can be that uh if there are any you know edge cases. So one client is you know implementing something which another client has not.

So if it does a comparison then it can say okay this particular client is missing this particular edge case that that can be another way of looking at it. Uh another thing which I haven't thought much about is learning from the previous security audit reports. So you know I'm assuming previously there have been a lot of you know security audits which captured uh some vulnerabilities. So if that particular knowledge base is also fed or trained uh then the AI this whole system can learn how to look for such kind of scenarios as well. Um so yeah there there are like three or four different ways of looking at it.

So maybe for starting point I can start with if the implementation actually matches the specs or not once that works fine and we have more confidence about this system working fine then we can move on to the security aspects. My question was for the PR tag like you have you mentioned that you need labels on every PR. Yes. So the no the assumption is currently there are no labels. So you fetch different form of label.

Yeah. labing uh in terms of like uh you fetch the uh PRs based on let's say keyword search for instance uh using the graphure API and then uh we store it in a vectorized form after chunking them. So it can be like if we store the entire PR or even sub PR so that because some PR are just way too big. Uh I checked like some of the big PRs have like above 100K context length. So I can't just put that entire PR directly.

The we need to figure out a way to actually chunk them in in a meaningful way and expose that to an MCP server. Uh because assuming the even you know the usual LMS have like 128k context length. So we have to work within that context also. And another followup is like for an EIP number sometimes the EIP evolves over time and it's like almost doesn't resemble its original form anymore. And I noticed with some of the when you ask about specifics of an IP even if you give it like a current link to this step it still pulls in that old information that Uh yeah.

Yeah. Which is why uh this knowledge base concept uh I mentioned. So you know I'm assuming this system will automatically update uh maybe once a week or something update its EIP knowledge bases um so that it is up to date. Yeah. uh but uh yeah there's also a an edge case so so to speak that uh the LLM itself might have been trained with an older version of the EIP but currently we're fading it with a fitting it with a new version of that EIP and hopefully it will you know take the newer ones seriously and also like during development sometimes the EIP gets outdated and like the spec is in some discord channel or some call like the EIP is not always the latest specification before it's on.

Okay. Uh you mean the the corresponding GitHub link does not have the latest open. Okay. Okay. Yeah.

If it changes very quickly then yeah figure out a better way. That's true. Like I think one example that's kind of ongoing is is So you get one that's actually salient. I haven't checked in the last like couple of weeks, but I know a month or two ago um that go to Forest and we've got some outdated information like a year or two ago. This is especially which have been just for some years like people know they want history that that has been goal and it's just that the exact steps and specificity have changed dramatically over that but this isn't case of the LM not updating agency the EIP has been like people the PR go some other I don't remember the number but apparently there's some other which is not called force which has the current history X3 but if you go to but people will still talk about 44s and say they're implementing like I'm check netherminded um their 1.

32 which is a few days ago and which is what they say EIP 4444 they did not implement EIP 444 They implemented a thing that is everyone colloally talks about but it does not correspond that the actual anywhere. So I mean and that's not the element's fault like that's yeah yeah I mean uh if that is not a straightforward way to actually get that knowledge it will be very hard like uh if let's say the GitHub repo of a particular IP if that is actually not getting updated and if we're expecting the knowledge base to exist in some corner of Slack or Discord yeah it will be very hard so seems like it would be useful to have like another agent that is sort of like historian or a librarian to some of these things that could help put some context to EIP that go through transitions like this. Yeah. Yeah. So, so I I just double checked this so that I'm not like Right.

So, I just checked right now on EIP's you know like for it is uh last created in 2021. It is quote unquote stagnant and it has there says nothing about like people might portal and all the various things that have come up and the exact time period and it currently is pre- merge and whatever people who they won't get into deals in detail if they care but the point is there's all sorts of relevant salient things and then when people today say they are implementing VIP 444 it bears essentially no resemblance to the thing that is called 44. Yeah. Yeah. I think it's 7642.

Like is that what it is? Yeah. I think there I'm told there was one. But before I pointed like if like if you just kind of parse out, you see the thing is we're just colloquial if it were only that people just said it because it was a name they like. That's that would be one thing.

But this is why specifically mentioned in the other mind and and other by the way um eels's change like this is formally what they are writing that they are implementing 444 all of the it written versions of it and when people talk about on ACD and and they all refer to this basically red herring IP such a system maybecept Yes. Yeah. There are certainly ways of of remediating this for sure. But I'm just saying this is a and I don't want to hyperfocus too much on this one thing. I just want to say as a concrete example like this this this phenomenon has occurred as well.

Yeah, that's a very good point. I wasn't aware of it. Yeah. Cool. I think that's we should this one up because we're over time a bit.

So, thank you so much S. [Applause] I'm Shane blockchain on Telegram, Discord, this type of thing. Uh, I flew a few thousand miles over here today to talk about delayed execution, EIP 7886. Um, a quick about me is that I've been building professionally in web 3 for the past three years. Uh before now I was a core team member at Injected Labs a Cosmos SDKbased L1 that was built for finance.

I joined the EPF program to do more applied research that will further the Ethereum roadmap. Uh and this particular EIP has potential to help with uh the scaling of the L1 aspect which we're all very focused on right now. uh there's potentially massive unlocks that it can deliver in terms of like increasing gas limits and even paving the way towards ZK EVM. So we'll take a quick look at uh Ethereum today and also what refactors you can make based off of this proposal. So here's a slot life cycle uh 12 seconds uh at the like fourth second that's when we're doing our attestation.

It's the attestation deadline. You can see how like most of the blocks like the time before then is used for propagation of a block and we keep the gas limit quite low in order to allow for only say 100 milliseconds worth of time for the actual execution of the transactions in the block. So let's uh then look at what would happen with delay execution. uh with this particular impmentmentation, we'll have a bit more time for the propagation of a block, but then we'll have multiple seconds afterwards to actually process the transactions. That's kind of the idea of delayed and that actual extra time between T4 and T12 could also be used for ZK EVM proving as well.

Understand they might need like six seconds somewhere in the next six months for that. And uh quickly what happens with block validation today. You can see something like the block header arrives with a current with a state that was proposed from say the builder and uh we'll then execute all the transactions on the execution layer to arrive at a new like world state tree root hash and we compare that to the state that we got in the header like the resulting one. If it matches, we say the block is valid. And currently then there is a really tight coupling of consensus with execution.

Basically very crucially need execution in the validation flow. The idea here now will be how do we decouple execution out of that. The idea is moving things around a bit. Uh you can see for like say like block n plus2 the header has a pre-state root field now. So it's a modified block header and this pre-state route should actually correspond to some cache results of the world state tree from the previous block.

So now like block n plus2 will reference the state from after executing block n plus1 and that allows us to do just a super quick header check and say a block is valid right before executing the transactions. Like at this point we'll be like the check will be hey does this pre-state root field match what we have just cached from executing the previous block. If so say it's valid then we can lazily execute the transactions for the like multiple seconds in the rest of the block which is quite nice. Uh you can see how that would allow us to have like bigger blocks and lots more time for uh like potentially me gains as well. So let's do a quick status of the IP.

Uh it's currently in draft. It was created by Franchesco Damato and Tony Washder. Um there is a EALS spec that's already out there for reference and uh it's a potential project that could be form and there are also like some alternative implementations that are more consensus layer focused like EPBS. This is kind of the more execution layer focused uh way to like get the unlocks that I've already mentioned. So we'll have a couple phases to implement this project.

And the first one is mostly regarding header changes. I already mentioned that we're going to now have to update to a pre-save route but also a few other fields from the parent block which would be you know like the parent transaction route, parent receipts route uh and a few other extra fields. So the execution payload that comes in from the engine API is going to have to hold these new fields and then we'll have to do some header struck changes as well like in in ref which is where I'll be implementing this uh project um to uh rip out those fields and use them as the header for validation uh and also all the RLP encoding changes that come along with that. Uh the second phase is much meteor. Uh ref supports a couple different validation flows.

One will be like their live sync path where you're processing new payloads coming in from the latest for choice. And then you also have a backfill sync path which will be for you know syncing nodes all the way up from Genesis uh blocks all the way up from Genesis. uh we'll make the changes that I kind of described you know like uh do the quick validation of those headers and then update the execution path to uh run afterwards and then do um any post transaction processing like if the block is decides to be invalid then it becomes actually a noop so add that logic as well um and of course we're going to want to do some testing and benchmarking uh which I can type a little bit more in terms of the challenges Um it'd be nice to do like N10 testing in a devet but uh I don't think we'll have the very like minor consensus layer changes we would need which would be like you know passing these new like pre-state uh root fields uh from the like beacon block body over to uh the execution layer which I would need. So I would just be writing like unit test and the best I can with that. Um other challenges are just like maintaining backwards compatibility with like the pre-fork uh validation flow which we have today.

Uh I don't think it'll probably be a non-trivial separation. And yeah, just closing thoughts. Um this is just one way to like rethink our current execution flow. It's a relatively lightweight change that has seemingly outsized benefits, which is one of the reasons why I like it. Uh thanks for listening everyone and open to any questions.

[Applause] I have one. Yes. How does this intersect with shortening slope? My understanding is compatible. Um, I'm not familiar enough with why, but I read a post from like Tony or Shatter a couple days ago that said that could be uh could be fine for it.

Yeah. Depends if if reconirmation if execution or gets implemented before or after short. Yeah. But most likely it is as you said I was just curious how things are viewed in this context of having I don't know six seconds. Yeah.

Yeah. I mean in theoretically if you still kept like that testation deadline at 4 seconds and you still have like the two seconds which is more than 100 milliseconds that we're currently allowing for which is kind of nice. Yeah. The more time you have the better. So yeah, we have kind of competing views of like keep the slot at 12 seconds, go down to six.

Um, so we'll see how it goes. But I think either way this could work. Yes. Yeah, of course. Yes.

I guess I will say that like a lot of the consensus teams probably haven't been working on this because it's just so up in the air right now to like EDS and stuff as well, of course. So if like you said, you in order for you to do some of your testing and stuff like that, you'll probably just reach one of our clients to to help make that work for your purposes, but I don't know if you reached out to anyone at Lighthouse yet or perhaps or I can help chat with you about that after. Yeah. No, I'd be happy to get some resource for me because yeah, getting into actual DevNet for testing would be particularly cool. I mean, it sounds like pretty lightweight changes on the CL.

So, if I can just have a fork of CL with my changes that I can use with my branch, that would be great, right? Yeah. As far as far as I know right now, like nobody has really been putting too much time into it just because of the uncertainty right now. But if if you do it, great. Yeah.

For sure. What the client? Yeah. Yeah. Thanks.

Yeah. Yes. Yes. Um, so I'm a bit confused how this actually works. Is the trick that you because you change the head to reference the previous state.

Is that like the main trick that allows you to execution time? That's exactly the main trick because like instead of like having to wait for all your transactions to process before you can like say payload is valid before that like 4 secondation deadline, you now are just like checking against like a cache of the previous blocks results with the header and just like boom quick. Then you can just like spend the rest of the slot actually executing this blocks transaction. But but is that like cache is that based locally or is that like you actually reference like all the work basically you would have to like cache the um like root state of the previous block and also like fork states as well too because you're always going to be having like some potential uh reorg choice update. So you want to have like a hashmap in the end of like block hash to these execution outputs the pre-state route transaction like parent transaction route this type of thing just in case you have to switch and you know some complexity with if like you have a node restart you might want to have like a replay of the block at that point to grab the execution outputs that you're missing right it's also the execution request like because um when you make a deposit or a withdrawal condition its like a smart contract interact and that one goes into request true so that one is also delayed I mean it's like the entire execution that get not just the state update the state update is not that we want to more execute transactions anything else thank [Applause] Okay, awesome.

Yeah, cool. Go ahead. Uh, hi, I'm Lee and uh I'm working on the pds optimization proposed by grand and my mentor is sol and uh yeah let's do a quick poll. Uh how many of you know like DS PDS or data validated something? Raise your hand.

Okay, cool. most of them use. Yeah, let's go. Uh so let's say we already have PDS there and also like uh uh grand they get like library called Rust KG and it's also a cool library and we want to see like if we can make the uh DS use this Rust KG library uh even faster like we can save a lot of time with like uh MSM and entity operations. Let's see how much and uh so the quick recap of what is data validated sampling and data sampling the idea is like it's very simple we want to decouple the data from the for node to some specific like storage network.

So which means like a light node and for don't need to store all of them because a lot of data actually not that useful after a certain period of time like a raw data but the tricky thing is like you want to make sure that all the data are available that's very important for the not only for verification but also for like reconstruction. Let's uh take an example. Uh if the like a rowup just crashed uh and some money already deposit locked in the row up, how can we like uh uh reconstruct the whole state? The idea is like the L1 for validator they can take the data from the DS node and then helps L2 to reconstruct the whole state. So which means even the like even if the whole L2 crash let's say the whole team like just run away but L1 can still guaranteeing like all the state is safe and all the money can be retrieved.

So that's why it's much better than a lot of other solutions and it's quite succinct and uh like u useful. Uh now we are using the KDG commitment. KG commitment is actually amazing for this part because for DS we actually has quite a lot uh uh crypto requirements like say uh we can now simply actually we can use a worker tree as a commitment scheme but which will involve a lot of uh more queries and uh much more complex uh like uh uh yeah like you need to check if the code is consistent Not only the position binding soundings all this stuff you also need to check if the code binding is there and uh but for KDG if we think if we assume like AGM model is safe then kg is safe and for kg it naturally actually can't fulfill all these requirements. So you if you don't know a lot about crypto things you just don't think about it. KG are already good enough for this situation.

it's it's safe until so far and uh so if we want to use a KG I mean it's already a lot of libraries like they already support uh KG but we also have something called like CD and RG want to do something is like they replace CG with a rust all the rust interface and we give like APIs like can use back end like artworks and uh like these curves to construct the KDG proof and more efficiently and also rather let's say KG has some something like uh uh some some major time consumption operations like multiscale operations entity and setup and setup is quite big but I mean it's roughly okay actually the setup is not the things that we are going to deal with here and also the b uh uh batch verification is quite nice but to generate the batch proof it's actually quite uh like time consuming also and now rag already support multi back end architectures like BT and Aquox and also others and BT already and aqu already supports uh parallel and uh GPU so uh we can see some performance ational benchmarks from roster if you cannot see the details of the figure. Oh yeah yeah yeah it's just small uh I can briefly explain that uh basically you can see if we use like GPO the performance get huge improved and it's also very natural right for the whole like uh kg like uh uh generation I don't see any parts we cannot parallel right and is a tricky part but we also have some way to make faster with like GPU and all these accelerators But the thing could be more interesting because for uh compared with native like KDG for PDS or DS we need actually it would be better to use like a batch verification right and uh if we can do like batch more efficiently that's going to be interesting and uh also like they have different back ends so for different back ends they will for different operations like MS entity and all the commitment verification they actually have different performance that's actually natural but also very interesting because for different tasks they may actually use different back ends they may the performance will maybe huge different but for Russ KG we all have the same API right which means you can simply swap from like change from uh this back end to the other one uh so the what we can do is like we have a like a back end selection that's actually kind of like a low hand fruit because if we have already for for PDS all these like task are quite uh uh clear right it's not like so many complex task it's quite extra simple task so if we know like which operations can be done this back can just use it right and another one is uh if we can do more operations for d specific things and uh uh also like GPU is good and if we can do more and also me uh memory layout. So we kind of have like another layer but maybe not really layer but they have have like optimizations for like Russ KG to support more complex like DS operations and uh yeah this is already thing I mentioned before and uh so the plan is like uh to first understand because I somehow I think I know the KG how KG works but for Rust and also the DS book but for rest I'm also new to that so I'm actually still learning that and then phase two going to be like we develop the like back end selection mechanism uh and also like say paralization and GPU optimization uh but I highly doubt if the GPU optimization could be fully done we can we can try some but if we can I finish all of them that can be amazing um yeah here actually once we once we need to use GPU for acceleration there are usually a lot of annoying things um and uh so now the current uh landscape is here um I can also skip this part and uh yeah for for us like uh the most important thing is like we use uh we need still keep psychology And we need to ensure that the all the operations is stable. And also we can starting to maybe not be done by the uh this project but we can start thinking about like not only is the proof is about net but also the network. There is a quite new paper recently uh uh released uh by Benet and other people.

Uh yeah, they are talking about about the bot of the uh uh DHT for the KG selection. That's kind of actually a quite interesting bottl neck because considering we need to you we uh for the safety we need to like have a lot of like uh uh D nodes like storage nodes but uh how to select which one to build a connection to query and to rec reconstruct this actually quite interesting and usually the network delays more than the proof right the proof we can use a lot of hard acceleration tools to make it faster But for a D network we cannot do much actually really. So not only the proof need to be fast also but need to be succinct which means but best also need need to be considered that's why B could be interesting right and uh yeah that's basically that's basically my plan and uh for the learning phase about the rust kiji I'm actually preparing something like rust the kilig book now I can show you the first chapter it's uh in like writing in Chinese. Yes. Because usually we starting from English, right?

And then we have like a lot of nice guys to translate to Chinese. I say, "Okay, I'm a Chinese native speaker. Let's start with Chinese and then translate to the English." Yeah. Yeah.

And uh so this chapter mainly talk about I mean you you don't understand Chinese but you I mean maybe some of them you know but I I but you understand the code right? Yeah. Right. So uh this this chapter introduce some like basic idea for electric curve and how to use raster kg and uh uh all the uh raster based curve uh like native back end to generate uh let's say uh to do the uh scalar operation to point operation and scalar multiplication and so you can use this notebook and examples to step by step to learn how to use not raster kg but also like raster back end all this curve stuff. So yeah, I think that should be a good I mean at least it's good for me to learn the stuff, right?

And I think that also should be helpful for many other people's because both like ellip curve and ros the learning curve we all know it's kind of steep. So it's not that easy and when you put two things together and without like a clear material people just feel scary and never going to use it. So I want this one step by step thing going to make people especially developer feel like life a little bit easier. Yeah. So, yeah, that's all questions and [Applause] in this last notebook, what you implement like point addition multiplication by scanner?

Yeah. Uh what like did you also implement? uh it's not it's not at here on so far because the verification of the uh multiplication is kind uh yeah here because they already have a like uh you can see this one and we also discussed like we have like three groups or maybe sometimes two groups like G1, G2 and GT and uh why this uh parent works from here like a parent verification example here but we will not go very details say why is the pairing here works we only show okay if you use this API and ideally the pairing will work so for developers you don't really need to dig into the rabbit hole of the crypto detailed crypto stuff right and u yeah we just know okay we have this tool and this is how it intentionally and how it works in predical And if you want to learn more about uh like other people if you want to learn more about critical stuff we already have a lot of nice courses like uh banas course and yeah any other questions uh I wanted to ask uh what are you using for GPU acceleration is cuda or uh it's not done by me actually it's the benchmark now it's like for GPU it's done by rust k already the brand new uh I I think they use like uh both teslas and they check both of them. Yeah. And both of them looks pretty fun.

I mean it's like uh especially for for DS part. Let's think about it. All the things can be parallel, right? I didn't see any parts that cannot but the reconstruction part is kind of interesting. But we don't really do reconstruction a lot.

Ideally we shouldn't do reconstruction anytime if the chain is still survived. So uh but the reconstruction itself cannot be easily accelerated with GPU but the verification piping all the part should be able to thank you what is pos uh this is the di diagram for the pole progress. Yeah. So uh in in each in each uh slot a set of validators is selected as inclusion list committee members. Uh each member build and go one inclusion list uh according to the view of their member pool.

Yeah. um uh the proposer and the tester of the next slot. Yeah. Uh monitor and uh validate uh and store and forward the valid incl. Yeah.

The proposal or the builder will include transactions from all collected inclusion list to his blocks. Yeah. And the proposites. Yeah. The last the testers only vote the proposals block if the block include all the transactions in there.

store the inclusion list. Okay. How how to implement it in grand? Yeah. So I I plan to split it into three parts.

Yeah. The first we can define the pipes and uh handle the external interactions. Second, we can focus on the duties of various roles. Last we can implement or test for the types and the external interactions. Uh it consists of two parts.

One is SSD types and P2P process. Yeah. The other is uh execution engine API invocation. For the part one, the focus is implement the inclusion list and the sign inclusion list SSD codec and followed by implement the handler for gossip publishing and receiving. Yeah.

Uh regarding uh part two, the task include add get inclusion list and update block with inclusion list and point invocation for the use as a validator and modify the new payload request with the arguments inclusion list transactions. Okay, according to the spike, I've I've sort out the six six duties of the following four rows. Let's let's take a look at uh one by one. Yeah. So the first duty for the validator uh it need look ahead the inclusion list committee silent.

Yeah. Al the sorry the diagram is the the can. Yeah. So after diving to the code uh grinding code I think we can add a structure similar to the own big community members to maintain the inclusion list committee members. Yeah.

And uh we can implement a function similar to update beacon committee subscription to update the assignment uh at the start of each uh epoch. Yeah. But but we don't need update the subnite subscription because the signing uh inclusion list is a global topic is not uh is not in the any sublines. Okay. Uh valid data also need small and forward the side inclusion list.

Yeah. So follow the branding's design. Yeah, we can register a call back function like unblock to invoke the fork choice module for validate the sign inclusion list and uh and we should add a catch. Yeah, catch it if it's valid and return the acceptance. Yeah.

Uh if we return accept the P2P layer will uh automatically forward this sign in this stuff. Yes. Okay. Uh the the last duty for the valid data uh it need the block with the inclusion list transactions. Yeah.

So we need change the process block function. Yeah. So for also follow the brandings design we can add a new branch. Yeah. uh and call the modified new payload and point in the engine API.

Yeah. With the arguments uh inclusion list transactions. Okay. Uh so as uh inclusionist community uh it needed the inclusion list. Yeah.

How how can we do that? So uh there is a main uh loop for the ticker. Yeah. So uh I think we can add a new ticker handler to call the new get inclusion list endpoint in the engine API that at the uh specific time. So uh branding uh divide the uh Each tick kite is uh 1 second for the uh 12 uh seconds time.

Yeah. So you can you can add a new tip t here. Yeah. After after get the inclionation list uh the validator can use it to build sign the inclusion list. Um okay similar for the similarly for the proposer.

Yeah, we also need to add a new Terror to call the new update block with inclusion this end point in the engine API to force include the transactions collected uh collected from the order inclusion list. Okay. The the last last duty is for the tester also the the the syncer sync community. Yeah. Uh it need a world block which include all the transactions all the inclusion transaction list.

So how to how to do this? Yeah. Uh we can we can utilize uh uh strct chain link. It it holds some it holds the block information and with some meta metadata. Yeah.

So we uh we can add a new metadata here. So it it's it can store whether the block contained all the inclusion list transactions which can be used by the p block group function to return the correct hand. uh a tester to vote. Okay. Uh so for the for test for testing uh I think regarding the regular unit test or the bench test if if needed uh we here we we need also add the new spike test for the foro and uh because there are some uh local net so we also need local net test for the for uh the road map uh the road map is divided into five stage uh align with the three implementation parts.

Yeah, the stage one and two cover the cover the first part. Yeah, I I think it need one or one five months for the for the stage three and the stage four address just the second part maybe maybe need a two or two points. The last stage is f focus on the testing and the optional to the PRC end point. Okay. [Applause] Any thoughts, questions, comments?

Okay. Yeah, we're a bit late, so let's move along, I guess. Thank you so much. Yeah, awesome. It was it was very well a very detailed.

Yeah. And um my name is Fahil and uh the project that I've chosen is implementing uh 785 for Aragon which is uh the personal implementation uh for the Aragon client and um yeah Aragon uh client is mainly like mostly used uh as a full archive node at at the E uh level but they also have u like a consensus layer. built inside of it. So yeah, this EIP basically uh is meant to be built for both the the E part and also the the seal part for and yeah what's the main uh idea behind uh uh fossil and why it was introduced was to tackle uh these issues and uh currently like how block building is being done is uh like We we know that it's most of like the few people who are currently building blocks and most of the most of most of the block building is uh being carried out by strong uh like very strong centralized uh entities. So that's like centralization aspect of the blog building which isn't great and uh also the censorship resistance which is also uh like people or the blog builders can like have the power to censor the transactions or of people and uh they have the power to control what gets in since yeah since these two things are tied to each And yeah this um yeah this is a high level overview which Greg also discussed and uh sort of uh at each slot we have like 16 uh members who get selected as uh committee members and um they basically uh search for the transactions and these searching can be done by any uh sort of um yeah any any sort of uh transaction selection process can be done here either based on pri priority fee or either like randomly or yeah it can also be based on yeah how long a transaction has been pended pending for in the mele.

So yeah once the each member have an IO view they basically post it uh on yeah via gossip sub to to the PHP network and u yeah these the global topic each member sends it and uh the currently uh currently uh in this in the spec we allow each member to at least send the IS twice which I'll discuss Why it's twice and not not more than two or why not not less than one or why why not less than two and yeah basically builders since it's on the global topic uh builders can uh basically listen for that topic get the iOS and uh if if let's say if uh like some builder have missed the inclusion uh list they can also uh they have also like an HTTP endpoint built inside so they can Uh yeah and get get the inclusion list from there as well. And yeah then once we have like all the inclusion lists uh at that uh time slot we basically the proposer builds the block and then the testers then verify uh if it's if if the block has been built and also checks the IO constraints on the block that if all the IO constraints are also being applied. Um yeah so these are basically like a very high level overview of the changes which will be done uh on each layer and uh for execution layer uh it's basically uh yeah before like the transaction execution when the transactions are being executed it will check if if the iOS if more I uh transactions can be added if if there was like a transaction gas which is uh like if if the transaction gas was uh less than like the current block can support more transactions. It will then uh send an invalid response to our uh consensus layer basically and yeah for the engine API changes we have introduced two new methods. So we have like get inclusion list v1 and then update payload.

And with get inclusion list we can uh basically communicate the inclusion list from uh e to the and uh with update payload uh what it allows you to do since the payload ID has already been generated. Uh what it will do is that on that same payload ID it can it will take like the inclusion list parameter as well as an argument and then for the same payload ID it will then add uh like the transactions for for for for for the previous for the same block it will then add all the inclusion list transactions uh for that payload and on the consensus layer we have like fork choice changes and the P2B topics which are also added so for the fork choice um changes like we have to also check uh for for the IOS which arrive we uh store them or cach it and then uh basically why we need to do so is we need to check if like another uh the same member have sent like u like two IOS and uh we need to make sure that they don't they are same and not different. So if they are different we then lower the score of that uh member. So yeah and we don't accept uh we don't include or forward values from uh that specific member and for the P2P topics as uh like I mentioned in uh this diagram we basically uh like the topic will be there so like each member can communicate uh or forward their IOS and uh yeah this is like how uh IOS are built basically it it can be it depends on the client implementers how they choose. But yeah, these or more can be added like how you uh sort of build your inclusion list can be based on the priority fee can be like how long the transaction has been pending or some custom logic how uh yeah how how the implementers select and uh yeah for for security uh we have uh like one of the sort of one main security consideration which is that what If uh let's say single uh member sends uh two IS or more IS now in that case like when the when they send more IS we uh potentially uh have to make sure that those are not forwarded anytime soon or next from those members since their uh peer score uh will be dropped and um yeah the reason is because they can easily confuse the other people and uh uh how they can confuse is that let's say Alice send like TX1, TX2, TX3 and then she sends three different uh uh transactions in the same.

Now the the tester will be confused against what they should check uh the block to verifi to uh basically verify if the block is valid according to the IO uh yeah according to the IO uh so yeah and uh the reason they have decided for two is because there can be a sort of scenario where they accidentally sent the same IELS and they don't want to uh sort of discourage or not discourage like they don't want to uh say that this member is uh bad because it was an honest mistake but let's say if they sent two IS but all of them were different then we need to discourage this behavior So yeah also like two and the the number of IS are restricted because we need to preserve uh the bandwidth and also yeah we basically don't want to flood the network with a lot of uh inclusion lists and uh yeah that's basically like it helps excruciate attacks ex exclication attacks and yeah that's that's pretty much it. Hi everybody, my name is and I'm here to talk a bit about my plan uh during this session. Also, I'm going to tell you about where I come from and what I want to do here and what I want to do after because I have kind of like a multi- multi-stage thing. So, I'm going to start with me. Um I think I'm a developer for 20 plus years.

Um I started in in the gaming industry. uh I jumped in the the web to stuff and yeah I went from leading teams to uh building my own projects to consulting for you know so I kind of done a lot of stuff in in that area um and I was on a like a right track to have a proper career and do what was expected of me and then I just said I don't want to do it anymore right u my I just stopped right so my shrink called it like crisis. I see it as an opportunity to to do something else, something that would give me something that would fulfill me, right? So then I met Dan who's right there, really smart guy. He was already working on the ODS uh which is a way of having delegations in in protocol.

Um we we talked a lot about uh public goods and just trying to you know use our skills and use the infrastructure and the community in in ETH to to do more right. Uh yeah then I decided to to work with Denon. There was quite a lot of work there. Um and I had to go through you know the normal hurdles uh look at the specs learn how to read them compile them look at the tests so the the learning curve was quite something but yeah I made it what I want to say is that during that time I found quite a lot of places where uh I think we can improve it as a whole uh I'm really keen on on pushing UX stuff more. U basically I want to increase the adoption uh for developers, for people, for anybody that wants to use this.

It should be I think way easier to to jump in than than it is now. At least that was my experience, right? Um yeah, so I decided to just go for it and see where that takes me. um a bit about EODS and I think we'll be releasing more more info this week and the weeks that that follow. Um we me and Dan just had some initial discussions.

Then we built a small prototype just to kind of validate our ideas on how things could work. Just a super small Python project and then we started working on the the space themselves. We are nearing the point where we want to kind of make things public and involve the community and you and everybody who's interested uh mainly to get some feedback right because we've been working yeah together uh limited health limited feedback from outside um and we do want to involve the community so my idea for this EPF initially was to uh to write the tests for the odds and also have a proof of concept implementation in in a client just to kind of understand what it would take to implement it to size it um try to read out things we forgot um and yeah something we can benchmark and play with in a in a test net somewhere uh so yeah that was what I was supposed to do and I'm still going to do it but I'm going to do it a bit different so um I was looking at clients and I found loadar which is a consensus client and that's easy to find out because it's written on their GitHub page. Um also saw they could use some help and nobody was really jumping in. Um my last couple of projects were TypeScript so I still have some muscle memory.

So I said okay I'm going to definitely want to help the guys. Um yeah so this is my plan. Uh I'm going to wait for feedback from community EODS wise and keep polishing the specs and so on but mainly I want to start helping the lowar guys. So they have a couple of tasks they posted some mira sport and backfield. I cannot tell you a lot about that because I couldn't jump in and did too much.

Uh but they sound like something interesting I can work on. I'm also not sure I can fit both of them in the in the EPF a lot of time because it's like we have four months left. So I'm going to try my best. Um and then once I I'm done with that I'm going to start doing the tests and the proof of concept uh fors by then I will be uh quite familiar with the architecture of loadar. I would get to meet the team.

So yeah I guess that would be interesting. So I'm definitely going to do the tests and the proof of concept I just cannot commit to fitting them in this four months right because proof of concept itself the implementation in a client is quite a big task for for one guy so yeah that's going to be my future moving forward. Yeah, that's it for me. [Applause] Thank you. Awesome.

Recently announced that they are migrating to some of their performance components. Okay. It doesn't have to be right. Yeah, I I still have not gotten in touch with anybody from their side. Uh so I'm a lot of there's a lot of stuff I don't know.

Uh but yeah, we're we're definitely going to connect and and find something to to do. I still want to do Loadar though. Awesome. Awesome. Thank you.

Thank you guys. This is amazing. Perfect. So, hi guys. This is my project.

My name is So, just a bit of context why Ethereum because basically I'm super interesting like the ethos of decentralization. So, one of my passion has always been like knowledge graph and infinite some game game theory. to me with Ethereum, the community, the principles, the values and yes, my project will probably also going to be on Loar. Basically, I was checking through their proposals. I found that Prisma was migrating also from uh from I mean from the from the test framework to crytosis.

Then one week ago I met a guy which is also developer in in Berlin and he told me that also lot was migrating and since I'm more familiar with 56 and then go probably I'm going to pick the lo way so motivation what so client lost what the testing environment and the scope basically is to help the team so I'm going to probably focus my journey uh helping the switching from logar test framework to cru what is ktos is basically it's a testing framework widely used in our ecosystem and uh basically it's a standalone development and testing platform for launching environment of container services in our case so in the ethereum ecosystem uh on the top it's built the helps team build this so-called Ethereum package which is basically able to spin up a private Ethereum test net or um death with a multiclient support. So whatever you want to build this this together with Ethereum packages it's going to be able to create it and here I added like a bit of code how you can do that pretty straightforward you can from a CLI you just run around etc etc. Here we have two type of examples. So on the left side this is how it looks like having um a network with um three nodes. Here the pairing is like get together with lighthouse and the one note with Netherite and on the right side here is what what I was trying during the week two of the EPF and started to see to simulate this network with one node BU together with this is the output of PTO is small current testing.

the status. So why migrating? So basically um I was chatting with the team and they explained me that like now the architecture suffice like these two layers. Layer one is a network boot layer that probably is going to be the one that will be migrated at the end of the of the migration journey and the second one is the assertion framework which is still going to be unaffected. So um what are these assertions?

Basically they simulate this this type of default test net and then they do this regular checks along the way during this simulation process and they assess how the test works are working and uh yes so basically they check for specific condition and performances everything is made through API um HTTP request so everything kind of still you don't access the the code here. I also put an image of the of the the current simulation report. This is how the the current testing environment looks like. This is the assertion that they are using. This is this is um from their code base and uh and yes go.

So the point is my project is going to like exp um exploratory phase together with investigation phase. So it's not like strictly defined so far how the migration is going to work. We are going to be researching testing out stuff. So breaking and building again and yeah so migration feibility go decision points. So this way or the other way um compared to Prisma that where they are going to like switch entirely the current testing framework probably lots are going to have this h soal hybrid approach so not migrating the whole u the whole code but I'm going to discuss with field and later and yeah so my scope is basically supported team and run the sim test and testing out the the migration the main question here is like can the current assertion framework be maintained while using for orchestration so basically remember that.

So this type of types of code is going to be maintained or also transition into this is what I'm going to be casting and yes angle is always like the ecosystem to standardization basically is not just from I mean is not the one trying to use that everyone kind of use it. So that's my that's my goal and feedback and question I think you can check out exactly exactly that's a point we don't know yet like whether to transition everything to a center or keep them separate. Yes, that's the point. Next question. Exactly the same.

Exactly. [Music] Perfecto. Awesome. Any more feedback for questions? Okay.

Thank you. I am Chips and uh this is something that I just thought around since yesterday after the beam day and this is more so of a feedback and discussion sort of thing going forward and if the slides look bad or rough around the edges or even sharp at center uh I'm sorry just be careful and uh the slides are just made in a hurry to look smart within a bunch of smart people so I can fit in. All right. So, uh, yesterday we had the beam day. A lot of folks, a lot of familiar faces from yesterday.

And, uh, one thing especially coming from a DevOps background that struck me was that, uh, observability has always been treated as like an afterthought, a secondass citizen by us developers. So uh I'd just like to briefly touch over why observability should never be an afterthought especially given that uh the current scenario and going that we have a beam chain uh that development is going on and how we can standardize a lot of things. So yeah early integration blah blah blah whatever let's keep it. So uh technical depth uh the beacon chain that is live right now the specs were finalized or it has been I I believe more than five around some like a lot of phes essentially so and yet there is no to minimal standardization for observability across the clients on the CM and each client of course they're free to do their own uh approach who to monitoring and uh but this what what what what what's the result of is that multi-client observability today is very hard there are tools uh especially uh big thanks to panda ops there are some tools that do give us a workar around but on a client level detailed metrics or other observability uh pillars are still not present so the opportunity with that that's supposed to be being chain I'm So beam chain is that since it is uh something new that we are starting from ground up there are not a lot of teams not a lot of concrete development even especially given the specs not being out yet uh we can have a standard uh for metrics across the clients we have a better understanding of a lot of things so we can just you know uh observability is not just your metrics it's not just your logs it's I will have a crash course right after this But now we have a lot of better understanding of MEV. We can we are trying to prevent MEV and trying to you know a lot of folks are trying to maximize it.

We as code developers are trying to minimize it. So we have have a lot of things that we can get out of just from observability that we do not have today and how we do it. We'll touch on that later on. So this is our chance to standardize observability today before teams diverge. Zam does something uh ream does something else.

Cox does do something else. We can have a standard set today and the first test net uh there is still time. So but we know things will break. Uh performance will be unpredictable. We will not know we will not even have a benchmark because it's the first time we're running that change.

So it will all be very helpful. So this is all that we will try to achieve. If we have something like this from the get- go we have the first test net for beam chain. So real time consensus these are just very basic things we will go in depth. Uh all right this is what I studied uh in my bachelors for past 3 years or so just consolidated bother down.

So metrics is just one part of observability. We have logs which we all use to debug somehow and we have traces. Uh how we can use those today is just like a log we can have a human readable form while data X makes Y due to Z reason let's say networkability metrics are mostly numerical mostly uh but could be your strings or any other data essentially but metrics also has various types. So we also need to make sure from the get- go if you want our metrics to be counters, if you want them to be summaries or whatn not. So and then traces your trace flows all of that and we can even have it in much better form.

But what I want us to focus on going forward with Z is profiling which is a new paradigm in observability. uh it correlates your other type of observability parameters with other things mostly time. So how much time since we have had a huge discussion about signatures their aggregation the size. So how much time is my signature aggregation taking? Your metrics will just tell time for let's say the call your but between calls between clients you cannot tell anything.

That is where profiling comes in. So uh this is the custom profiling section is what are some examples that we can have going forward with the development. So how much time is my aggregation taking? it it's like your trace is given an additional information data point most of the time. So there are some existing tools.

What's the difference and why do we need this is we have uh thanks to panops. So ethereum metric exporter it is again for metrics a it works great across clients very well. Uh but the shortcoming is it it uses the standard APIs that we expose. So I can track how much is the the JSON RPC uh response time but I will never know how much CPU did the client use. I will never know what was the flow of the request or where did the bottleneck come from.

That is again the limitation of u the architecture that we're using and again because it it had to be standardized across clients. It made sense but right now given that we are in very early stage of development for beam chain clients we could have these things from the get-go. So we get a much better understanding and down the line we have a much better uh playground of data that we can use to optimize things. you know we create new EIPs and we can create new optimizations as code developers based on this actual data and there is tracer and a lot of other tools. So uh some this is this code just ignore it for it's just very bad examples of things that we can do but these are practical recommendations on how and uh what approach we could take with observability when we are going forward a lot of uh re folks are over here drape from Zim uh here we have talked so we might not know each other with face so uh Ze folks are here as well but so uh And Mario just told me that there are you know uh clients like guest which allow for hybrid models for data saving for metrics but also your data saving for logs which is uh uh and your uh traces and all that we should ideally aim for a plug and play so that we do not get like logged into a ecosystem or a a standard essentially that is a and second thing would be uh I I have seen it myself.

A lot of organizations, a lot of folks using these just because we have obserability as an afterthought get logged into something like say like data dog like New Relic because they do not think of it from the get- go and now uh we talk about decentralization. Of course we we can talk about it a lot in terms of the infrastructure we using and what not but we get logged in by some observability vendor which has full control over what we see and if they want to turn off their cute little buttons for metrics they can go right now. So the idea is again this is something that I would like some feedback on as well to have pluggable structure not just for databases of the metrics that we're going to use at the standards for it or and other tools as well. So avoid when the lock in uh built-in client instrumentation uh since that we have example of the panops tools which works across the client but are not as detailed because of the limitations uh and then standardized metrics. Of course your implementation will have different let's say labels for your metrics but it's always good to have because a few things are always going to be standard right.

uh we can have those standard at least and real time profiling and this was it. So uh what is this? How can we balance? Yeah. Okay.

Yeah, this is the question for you. So if there is any feedback uh I'd love to get that. It's very impromptu presentation and thank you for your time [Applause] everyone. uh questions, thoughts, uh answers. Yeah.

Yeah. I it seems like there's a different categories and obviously didn't sort of you presented them as sort of different different approaches. You said metrics and and of course they're different things. Some of them seem I mean metrics are quite conventional as you say they're not standardized now but every world has some selection of them. They Yes.

Yes. Um others are as you know less conventional like but I'm kind of curious in terms of your vision for things that so there's some are sort of let's call them um policy there's a standardization of things of this sort and we have at least one person here who I know is is uh pursuing these things but but the um but at least in terms of a technical measure those are I mean we know how to do that. We know how for the debugability and profiling. I'm a little curious because this is um a couple points traditionally quite language dependent also definitely there's also um and even in terms of it feedability in terms of like uh dependence optimization level in terms of debugability uh traditional debuggers stop the program I mean could could you come again with that they stop the program uh what exactly sorry could you repeat what exactly stops traditional debuggers And here I include things like RR. So I'm not just in the sense of well they step forward like GDP or something but even the ones we can time travel and and all of that they stop the program like I don't know that's kind of a showstopper for me in terms of like using them in in a wide real time way.

I I'm not quite sure I'm curious. So so one question how practically do you envision it happening and and also in terms of profiling um there's a similar where of course people who have built um probes like look at Linux and some of the EVPF stop uh stop is and and so there are certainly ways of building profiling things again that's always in that Linux context for example they have to be very careful about the performance overhead and if you look at something DM message like kernel box sometimes it will just say hey well it's decreasing the frequency the sampling frequency because the sampling overhead is too high and so I just want to so what I guess those would be my my questions. Yes. Yes. Sure.

So let's I I believe that that that's a bunch of question. Let's have them No worries. No worries. So uh this is one of the ideas submitted to Panda Ops by uh for the EPF and it's it's just metrics. Let's just start about the standardization.

Right. So the the point of standardization is not to force teams to use one specific way of how they approach their you know the core logic that is going to be part of the client but to ensure that the visibility of the core logic is standard across the clients. So if I go to let's say ze if I go to reim if I go to any any other client uh the core things let's say how much time is it taking to uh aggregate the signatures how many signers are there and uh anything basically right so at least that and if you want to do it in some weird way or some very smart way that is up to the team but at least as an observer I should know right so let's is you you run up a node right you want to be able to see uh what you are uh like what exactly is your client doing right uh but let's say you find something that you know this client is not working for me I want to switch now you switch to the other client and the other client does not even show what made you switch so let's say it was the time taken to do something some action X and now you go to client Y and you you do not even have that metric right so there is no even you cannot even compare. So that is the the the kind of standardization not not in terms of the goal logic. Uh the second major thing was the overhead right.

So again it's always trade-offs for us. So you want to have as or also with metrics especially if we talk about metrics. So we have all these labels but the thing about metrics especially in Prometheus is that every label that you add each entry uh each unique entry will have a separate time series database. So let's say I have just two labels but each of the two labels has like 50 possible options. So it will be 50 into 50 uh number of time series database that the Prometheus will make.

So we want to limit those things. So again that that is where we do performance optimization for observability. So again it's at the end of the day yes it is a trade-off boring answer I'm sorry but uh it is how we deal with things uh everywhere. So we'll have to make sure we have enough data to allow decision making and improvements but also not too much data that our clients have issues in performance and uh we fall back on the actual use case. Boring answer I'm sorry.

So so I mean and to follow up a little I mean is this actually what you're the what you put up there like So I would say some of those there's there's a distinction um between some some of those are accessible at the application layer of the CL and others are not because some of those are gossip all not actually all the things you label as gossip submetrics are are inaccessible but some of them kind of are so in particular the including duplicates is not actually accessible generally speaking I can't speak for all the P2P But like the function of the whip PDP library is partly to do this abstraction abstraction and and to do this duplicate detection. One of the many things it's doing and usually it is not supposed to deliver the same message over and over and over again to the client which means that the application level layer sorry level layer of the client is is not going to be able to even ever see what those are. means that we look those are a kind of random mix that are of unlabelled which is which some of those have to live in the lip p layer some of those can live in the application layer lip pip is not just like some ethereum library has other use cases and so it's worth being a little careful there is how like in terms of the standardization process like how this This is so this is not simply asserted by Ethereum on behalf of all the P2P right we're not standardizing what li P2P does but you you are that that is this is the metrics that we our client would expose so see uh uh let me give give an example so this is my function right that is lip something doing over here right now could I not profile this function could I not just call metrics from here to this point which was the lip p2p call I'm not doing any changes to lip p2p I I I could easily do that and that is like near to zero just for one thing performance overhead and you are not changing you are not forcing lip p2p folks to align to ethereal that's the very basic example but uh I hope that clears it up and also this is this is basically labels on the client level so this is what panda ops wish is to standardize. So this is what Nimbus is doing. You want to you want to update the table and open a PR because it's probably it's like year old.

Yeah, it it is very old and I I believe some of it has been worked on already as well. Yeah, I I have a look at it. So when we're not enforcing anything on lip or any other library which which should never be the goal as well, right? So we are working on Ethereum and it should be aligned with our standardization not forcing anybody to enforce our standards. Yeah, that that was the point of the presentation.

I'm sorry if I I could convey it in a way but that is what I meant from the get go. Okay, any other questions? I think we need to cut it on time. Yeah, more of a Q&A I guess than a discussion because Yeah, I wanted to have like our 90 minutes and we have like 30 minutes to do it. I'm Thank you.

Um so, uh let's just get going. Thank you so much for being here. Uh we got Phil from Lonear, Mano from Prism and um uh and Dan from the EPF5 working on EODS independently. Um so uh um all kinds of different people here from from uh different backgrounds and um I would like you to share uh kind of your journey how what brought you to the um uh brought you to the core development and uh how was uh how was it for you uh to get started? um if you could just tell us uh what was the journey for you uh what brought you to Ethereum uh what was the first contributions you made and yeah how how was the journey for you and let's start with Phil because these guys are from EPA they will have a similar story a bit but uh Phil and I think you have some military background or so I'm curious your journey so yeah my journey so I'm not really like I didn't study computer science didn't say computer engineering and that stuff I came from a IT background I used to work in the Canadian military Um, and through there I learned a lot about cryptography and and stuff that would make it easier for me to understand this stuff.

So everything I uh got into blockchain in general in 2013 when someone sent me some Bitcoin um as an example in 2013. Um, from that point on, you know, I was lucky to have grown up in Toronto and there was a big uh Bitcoin and Ethereum uh scene there in the early days. So started uh learning a bit about at that time in 2015 with uh through the homestead fork uh when when Ethereum officially got out of out of its test nets, been following that throughout my time and then only went full-time into Ethereum in 2021 when I joined Chainsafe. Um so from that point on um I had been contributing to web 3JS and to um Roadstar. uh we proposed our first block on mainet in 2021 uh November.

From that point um basically stayed with the team. I loved the work that we were doing and um pretty much kept going with it from that point on. Awesome. Yeah. Thank you so much.

Um so it's been it's been many years since you started looking into crypto to actually started working there. Um like what what were you learning or what what brought you to chain? You kind of skipped it part like how did you adapt? Yeah. So, I was kind of just like following the developments.

Um, I was a tinkerer. So, I used to one of the first coins I mined was Dogecoin, you know, with my like with my home PC, a gaming computer that I wasn't using. It was like a old Radeon like 4,000 something like that. Um, and then through that just started learning, doing a bit more things. Um, and slowly gaining the knowledge that I needed to eventually feel comfortable to even contributing.

So, my journey was a little bit longer and a little bit slower because I was working full-time military and doing everything else on the side um because this is what interested me. And my goal one day was to get out of my full-time job and then find my way into blockchain full-time. And that was um which I think is very resemblant of a lot of people's journeys. It's how do I go from my current full-time job that I don't like in web two or some other world and bring all of my skills into web three and actually start getting paid to do what I like to do. Yeah.

Awesome. Thanks so much, Phil. Yeah. Okay. It's funny because I also had a military background, mechanical military background from like long time ago.

Yeah, I think I start to mine some in 2017. I have like 17 GPUs in my home. 17. Oh my god. It was my heater know in the winter I Yeah, it was fun.

And yeah, later on I I joined a company named Kil. It's a staking company some of you know. And yes, I was managing the serum sting infrastructure. And yeah, and so I saw some bugs in I was a heavy user of te like other guest and so I I saw some bugs I just submitted some some some reports some and yeah I said after I just saw that the EPF program it was EPF3 it was three years ago I think I applied I worked on prison and then after few months ago I started to work full time on prison since two years something like that for two years. Um yeah, basically that's my story.

Awesome. Thank you Manu. So Manu is from the EPF3 from the first cover that we organized with Josh and like also my my t-shirt is from Denver from our first EPF day actually. So this is the third fourth one but yeah that was the the first one we did. Yeah.

Awesome. And the EPF5 Dan. So yeah you can tell us about your journey. So I'm an engineer. I basically I think I'm some sort of a converted non-believer because if you ask me maybe four or five years ago about Bitcoin I didn't know what Ethereum is but I would say no it's not regulated.

So yeah, uh me on boarding on a blockchain first on app layer was because I needed I have a company that does engineerings in water sector of the water sector and my company needed a loan and of course bank said it was co and stuff like that and a friend said hey look into DeFi you might find something interesting there regarding nobody asking how do you have the collateral from where do you have the collateral to to get a you know a loan and stuff like that. So in the end I uh leaving that aside I ended up in a reflexer community the ones that issue rise stable coin I don't guys know it it's like in my perspective at least it's the most decentralized and you know sensor ship resistance uh protocols that are out there didn't get traction too much though uh so in that community I learned the value of you know holding your own keys and holding your Yeah, basically the wrong points. Uh and uh we had a issue with uh with Ryan not not accepting state is is just raw is because of security uh issues and then there was some discussions with with Vitalic and we looked into what would it take for protocol like right to accept state and that got me into to look actually what staking is at the protocol level and if there's something to uh to be done. There's still at this point no no no stable coin issuer that uh would mean stable coins just based on your staking proof. So they're all basically looking towards liquid staking.

Uh then I joined looking into this I I joined and Joshua for the first study group. I never looked back. Basically after that I put everything on the side and said that's it and the study group was great. We we form a nice uh group. We initiated a nice knowledge base and then we moved into the cohort and yeah and I got into EODS again it's like build it because we need it or something like that.

So I'm grateful for for the chances also I got awesome. Yeah. Thank you Dan. Awesome. Yeah.

So yeah we have Dan from the very latest cohort also from the study group. Manu from the first cohort even before the study group and Phil even before the EPF was a thing. So yeah uh different experiences but I wonder like what um something that you could share something that was a revelation for you or something that you wish you knew at the time you were starting. What uh what is something that you learned? Something that you uh some challenge that you overcame and you wish you knew it before you had to deal with this uh something that people starting their core development journey should know.

Uh and uh I I have I don't want them to you know uh learn it the hard way. So if there is something that you wish you you learn the easy way. Uh now you have the chance to them if anything comes to mind whoever feels like it. Yeah. Uh, I might have one.

Okay. So, like I think what a lot of people misunderstand is like if there's like some sort of a a standard way or like a ladder to or a road map to becoming like a core developer or anything like that. In the case of Ethereum, we are like truly decentralized in this matter. Like there is no one path to get to core contribution. A lot of the people that we actually find either we meet at conferences, we um we accept their PRs on our repos, people just show up and start contributing is really like something that I wish like more people knew because a lot of people do come and be like, "Oh, how do I, you know, become a core dev?"

And it's like there is no real answer to that. It's kind of like you just everybody comes from like various uh various worlds, various skill sets and stuff like that and have something unique that they can contribute to the ecosystem and it truly is permissionless like no one is going to you know necessarily say no you can't be a core dev like that's just not how it works and if I were to tell you my journey you know um or somebody else's journey on the loadar team it's very very different for each of them and if you guys are looking to find your way into core development it's very much like a choose your own adventure but also like you know people do notice in the community when you are contributing work. So a lot of the times like we you know everything is open so we're able to see the work that you're contributing um the skill sets that you bring the experiences that you bring and if it aligns well with what we're trying to do depending on which project you're looking to join um you know people will take notice and they'll reach out and see what we can do to help you. Awesome. Yeah.

I think that's really nice. Yeah. Okay. Something I learned is I think writing a client which works 99% of the time is actually quite easy. But writing a which works 99.

9% of the time or even 100% of the time, this one is very hard. Um because even in the specification or in the implementation, we have to we have to spend a lot of time of of energy to think about really not the standard case but the the the bad case is not the case you you don't want to happen network like lack of finality or some nodes which are going wrong or everything that could happen and that will probably never happen and so which is something which is quite interesting is I think we we learn We we write a lot of code which will actually normally never be executed like because in a normal network you don't don't need to get into this code pass which is know only executed if if things are going wrong but um as we saw a few weeks ago with hleski maybe you people know um so when we try to upgrade from um uh from detent to we had a lot of issues And this really proves that yes, we need really to think about deeply and to implement correctly all this niche case um which are only only executed if the network is is not doing so well. Yeah. Yeah. Awesome.

Awesome. I think it's hard to be perfect in theory like we strive for perfection but it's it's impossible to be perfect actually. Yes. And you have to to admit it and you have to admit that okay you have you can be almost perfect like 99.9% and reaching um coming from 99 to 99 to 95 will require twice the amount of work and so you have to say okay I I I will stop here I hope other clients with diversity will do 99.

9% but I hope that one% is not the same than than us and so if there is an issue hopefully Not all clients will have the same at the same time. That's why client diversity is is really important. And yes, this cover this kind of the fact that nobody will have n 100% of you know coverage there is still some problems and it should be okay thanks to cloud. Yeah. Thank you m from your perspective.

Yeah. I wanted to relate a bit um to the EPF the cohort itself. I to paraphrase team uh EPF is the most in institutionalized uh way to enter into Ethereum. Of course like in quotes. So it is one of the governance ways to on board people on protocol.

So, of course, it's a personal bias here because we had such a good time in EPF5 that I can only recommend EPF, but it is a it is an official way to go into Ethereum for you guys. And uh what I've learned uh I cannot say it's not necessarily the hard way, but I didn't know it at the beginning that Don't expect to be held hands. So pick up yourself and put in the work and results come invariably after. So so yeah thank you then that's very good advice. Awesome.

Awesome. And um so uh before I uh open for questions, I have one more uh to be also a bit more technical maybe because recently especially this year I feel like the it's been most like disruptive when it's happening around the protocol most uh uh focus on making things faster and better and like uh picking our governance processes and so on and it also reflects on the client teams and I wonder like um whether there is something specifically that you are excited about something that you are worried about? What are some um cool or challenging things that you are dealing with today uh in your work in your client or research? Like how do you feel about uh yeah upcoming challenges or some cool new features? Anyone?

Uh sorry. Um so as uh some of the Nimbus guys already mentioned like Lokar did do quite a large pivot you can say it's very similar to I guess the the new road map the more clearer road map of the foundation as to what they want to be doing at the base layer uh which is you know to to scale L1 scale blobs and the UX which you probably heard of many times now but this has been like actually the most direction that client teams that's gone in in quite a while it's actually like kind of refreshing to hear because there is a direction. Some may not agree, some do, and but at least there's a direction. So, at least for us at Loadar, um you know, back in 2019, 2018 when the project started, there was a lot of um uh interest at the time, thinking that like JavaScript tooling would have been like a really big thing as part of the E2 transition back in those days when uh we envisioned the beacon chain. But as you can see, a lot of this has sort of pivoted a little bit.

You can even see some uh tooling like even ethereumjs unfortunately not you know survive uh the transition uh with the EF. Um so there are some things that we are aware of that we are going to try to do to make ourselves much more useful at the base layer and not necessarily focusing on like a TypeScriptbased implementation. We're going to actually do what Ethereum needs of us and which is really scale blocks on the consensus layer. So for us, one of the most exciting things now is we're going to um utilize uh bun runtime which is also written in Zigg and which we've seen quite a bit of optimization even just switching from Node.js to bun runtime um and also rewriting some of our core modules in in zinc because we found that going native on a lot of these things will allow us to basically keep up with the road map if we're going to scale 7 to 72 blobs and higher than that um we need to ensure that like we're capable of doing that.

So at least for Loonear like we're very excited to actually contribute more to like the Zig Ethereum ecosystem even though more in the beacon chain side of things. Um, and those are some of the challenges that we've been dealing with on our side is really ensuring that we can continue to serve Ethereum as well as Lighthouse and Prism and all the other guys are doing um and and not fall behind basically. So that's what we're excited about. Awesome. Yeah, thank you so much.

Yeah, that's very exciting. I think it's also like sort of a new language exciting new thing. So, uh it's Yeah, exciting to hear. Yeah. What are you guys excited about or worried about?

Yeah. Well, I'm really exciting about this new road map of EF as you said SC1 um and even know on the short term like eps like kas of course which I am working on the things the most important for me for me is improve your I mean um even us know which who are in in the domain um it's I think it's still hard when you want to really interact with the network, you have to take your ledger or any, you know, any wallet and have to plug it and okay, I have to put my password. Oh, okay. Actually, it was too long when I was to when I had to to do some stuff of the computer and then I have to pass. Oh, okay.

I forget it. Um, and you submit the transaction. Oh, no. Before you have to swap to to allow for for the token swap. Um, and then you can you can run, but the gas price increases.

So, it's really hard. for us to to to use it. I really think that will win when people will use without testing they actually use it. Um when you use a computer when you use it doesn't know you are using Intel CPU with a 32 GB of RAM with a Linux core you know just you use it is very very natural and yes and I really think that's the most important point is this improve stuff and UX very large of course could be the spot time because we want transaction to appear on change faster um and not be We are and also really basic not basic stuff and really standard stuff like the front end of the of the of the of the wallet like react stuff should be really improved to yeah on board next billion users and it is really exciting. I'm really happy that EF thinks that it is an important thing to do.

Yeah, I agree. I should have been the first place, right? Yes, I agree. Not the first first place. Yeah, I think I think it's the third one just because we don't know how to do it yet.

Sorry. Yeah, thanks so much. That's awesome. Yeah. And Dan, do you have any thoughts?

Yeah, like research wise for on this perspective. I'm also Yeah. pretty excited about the the road map. Basically reading beam chain road map. I understood for myself that it's not it's not going to be a refactorization of the of the specs or of the clients.

I don't think we will have you know you guys maybe you can tell us. I don't think we will have like new clients. I don't think that's going to be the case. It's like more likely we're going to have sub subsential up to a point like having shorten times SSF actually that's probably later and then we're going to go to ZK ZVM notification of the beacon chain yeah uh and then SSF so basically that's how I perceived reading the road map so it's I don't think that we're going to have like a tabarasa and then rewrite the protocol so the protocol we have now apply them the most important upgrades. So we have shorter slot times SSF improve UX by the way there's done this fast confirmation you know you guys know about it yeah they picked it up might be something interesting yeah we have some fellows interested in FCR yeah okay yeah uh and then ZK I'm not expert in these things but for me having zkm plus ification of the of the beacon chain is like after that we run the protocol on the smartwatch.

So you actually see that the B chain will be just yet another fork. Yes. I don't think so. I I saw it in the but I agree with you actually when I say when I see you agree or disagree agree agree when I see maybe not but for me switching from chain to chain it's like switching from fusion nuclear wip to a fusion one you change the core of the system I mean it's totally different but it's not a different thing but yeah 90% is the same I mean you still need P2P you still need an API you still need yeah you still need I don't know for database and so the core is changing but the rest is is the same and that's why I kind of agree that big chain could be just yet another form I think it yeah I see I see the the the contributions people are making to beam right now is very much like trying to pave a way for us to basically transition too. So, you know, it's great that they have the ability to do a lot of the experimental things like three spot finality and stuff like this where they can actually test out these future futuristic theories and implement them because client teams that are maintaining the beacon chain, we have like no resources to necessarily contribute to that like we're we're still figuring off here at NAS you know so it's like you know the way that I see it it's kind of like you know very much like a a parallel stream happening uh but eventually you know like the the stuff that the beam chain clients will figure out for our future eventually will just downstream help us you know give us like a bit of a guiding light as to where we're going I may ask are they are there going to be beam chain clients or it's you is going to uh upgrade to that.

It's it's hard to say at this point because at the end of the day like like you like you said like 90% of of it is basically stuff that we already have and we just need to do like a few tweaks here and there um to to to you know get us from a beacon chain state to a beam chain state. I mean there are be beam clients right now. We have a couple of contributors here but they are just implementing as a beacon chain. They're just implementing the features but what but there is no spec yet. So what I'm worried about is that um maybe you could know more about it like that we will have to uh we will repeat the same mistakes like with a beacon chain when like prison for example was the first client but the specs were changing and like 2018 19 the beginning of the the prism is different than 2021 actual beacon chain prison round right so I'm worried about bit about chain these bunch of these contributions right now I think they are useful for prototyping uh but it will vastly different in couple of years or so.

Yeah. Uh cool. We get to technical discussion as well. But uh we have still a couple of minutes uh questions, comments, thoughts uh uh on for all of them or individually if you have any uh questions about being a cord. Something we discussed about your journey or technical questions um about uh yeah anything goes.

Yeah. Uh yeah. Hi. Uh I have a question about They actually briefly uh check their like language description before it looks pretty like the C and uh I'm wondering how's your feeling about using that compared to say and other languages and especially for like large project and also like with network stuff. Oh, that's a really good question.

we're really just like touching the surface right now and I don't like I don't have as much experience with with that. Um so I wouldn't be able to you know give you an answer to that question unfortunately. Um but yeah like some of the there are two guys on our team right now that are focused on our Loadar V2 right now and they're the ones that are really um digging deep into into uh Zing and uh yeah sorry I wish I could provide you with more information. Yeah, I'm a big fan of C and but I find like for large project it looks like pretty hard sometimes. Yeah, it is like very like leading edge stuff.

So we are like aware of just like perhaps like the unknowns I guess that we might run into like even something like the bun runtime is still like I don't know if it's really been used in a a large scale project in production yet right so it's very much like it's very exploratory and and we are aware of it like there's ongoing debates about where we you know continue maintaining and supporting uh nojs maybe even dino you know we'll we'll see there's a lot of discussion right now for sure that you think I mean that's great trail blazing right so yeah trailblazing like we like we are definitely pushing Typescript to its limits already and you've already seen like we could only go so far with it so yeah I saw Microsoft wanted to rewrite TypeScript in Go now they did Yeah, we needed that like years ago. It's too late. It's too late. Yeah. Right.

Um Yeah, folks. Um any more questions? We have bunch of cool people here. You can ask anything you can get advice. Yeah.

Yeah. So, we often talk about how like there has been 100% of time on Ethereum and you being called that. So, we we develop you develop the clients, right? So but unlike like traditional logs where you know you run the infra and everything like at 2 a.m.

you have calls so something must have gone like at at once when you know at 2 a.m. your colleague calls yeah she hit the fan get up so how common is that and and how how is that dealt with at the level because if there is a critical bug you cannot just you know change overnight. Yeah. Yeah.

instant response. So I don't really agree that I don't agree that there is 100% of time on net zero because there is there is no mean I mean if we miss a block availability miss if you miss a block it's like 12 second of down time I mean but yeah and you can see a lot of blocks now uh but yes we had% of time or of time where at least one blocks per minute was published and almost% of time of finality of minute about your question. Yeah. So I can speak as c developer and an operator because before I was operator and yes I was sometimes um page at 2 in the morning but I it was more for sol. Yeah, actually quite if you for example if a client has an issue um and you are not operator you can switch I mean if there is an issue with prison you switch or to any other one and normally it should solve I mean if the issue is not at the exact same area for for several times and yes um and as a car developer if you have an issue with your clients so it's quite embarrassing but yes I mean you don't need to wake up at because it won't show anything.

You wake up at what night, you fix the bug and people won't upgrade their node normally before a few hours. So you you wait up you you you figure out what is going wrong you fix it and you publish a patch and you say oh people please please of brain and thanks to the play actually you can we can have this chill window fix because thanks to play which is not the case of for example that's why it was when we had a bug to fix that and upgrade that. Yeah. Yeah. Basically like just quickly adding to that I mean as long as we try to keep our um our largest client share under 33% we can at least prevent non-fality if there is like a you know consensus or a bug on a specific client.

So a lot of the times we'll pick up each other's slack, but we need node operators to actually be running multi-client setups to be able to benefit from this. Like one of the things that we saw on on holy was that a lot of people weren't running breath and aragon nodes as an example and that created a huge problem because they were the only ones on the correct minority chain at the time. And then when you have that happening, uh, if very few people are running these nodes, it's really difficult for you to get synced onto the correct chain when there's already so few. You're basically liked the healthy ones and once they fall out, like syncing is a is a terrible nightmare when you have a situation where the chain is just not happy with with like it's just confused most of the time. One few minutes ago, I talked about working on code which almost never used.

I was specifically thinking about thinking thinking in a difficult condition. It's really hard because and especially with sharding because you don't know which is on the on the good chain and if it is on the good chain maybe the pier has not the data you did and yes and thinking in difficult condition is yes probably difficult. Yeah. Another shout out to anybody who's like really good with like testing like um like we a lot of people testing our clients in very terrible conditions. Like that actually helps quite a bit and we generally don't have time to test anything outside of the happy cases.

So like more like hats off to the pandoff guys and stuff like we need a lot. Yeah, I think the whole incident teach us a lot like we learned a lot there because there never been such a situation and like during the whole beacon chain like uh never experience such a thing but um yeah um but actually now the incident response is improved as well like the process that we have now around hard forks there are dedicated people from client teams who should be like on call in the given time zone when the the fork is happening. Um and then I was also had issues and uh and we we were at an event with EF with Panda Ops and it was like a couple minutes after the fork and suddenly all of the Panda ops and get team just stands up right and we yeah um yeah uh cool let's uh let's do one more questions um uh we have time for one more maybe if there is anything you would like to ask uh let's um let's wrap it up somehow anybody Josh, will Ethereum need cord apps forever? Um, I think I mean I think devs the the dev job will change a lot. I specifically thinking about LN and CL code.

We we use more and more code. Um there will always be I guess people able to think about how the protocol should work to write the spec or not only spec but really to think about the architecture of it and so he has the spec and maybe will write convert the spec into into code but for sure we will still need people able to code review to code review to be sure that there is nothing which is missing because writing the code is not really the interesting part. Uh interesting part is thinking about the design and be sure that you have a very good design and very good coverage for all the small edge cases that may miss. I I think for there will always be some core devs whether or not you need as many um in the future that you know depends I guess on if we're happy with oification at some point um but you know just looking at it right now it doesn't seem like it. So, um, very much like I feel like we're going to need core devs in the near mediumterm future at the very least.

Like we just don't have enough people, I think, especially in the implementation side to like do what we want to do. I feel like um but yeah, it's hard to say like what's after like you know quantum computing like we might might still need to you know maintainers maintainers after classification you get maintenance forever and well if you want to keep client diversity you need maintenance of each client right so it's still a lot of people and there always will be some small upgrades or some I guess some breakthroughs in technology yeah if we keep progressing we hope that you know would progress with it because you know even Bitcoin at some point is going to have to upgrade it cryptography so But I like the sci-fi idea that like we scale Ethereum that much that we run AI on Ethereum that's repairing itself, right? Self replication. And then you need AI diversity. Okay.

Okay. I think we can wrap it up here. Okay. Thank you, Dan Manu. Thank you so much.

It was great. And we'll see you for dinner. So, what time? 77 7:00 p.m.