Lean Client Architecture - Kolby

Colby, thank you so much for being here. Folks, we have Colby here from RE lean consensus client uh implementing the rest called RE um a core developer who actually went through uh the program before it was called EPF. He was uh working on uh portal network in Ethereum foundation and now on the future of Ethereum in lean. Yeah. Uh it's very exciting.

We had some uh general intro to uh lean before. So now looking into the actual fundamentals of how it works, how it's implemented. It's very exciting. Thank you so much for for joining us and we have we have 27 people so I think uh right ready to start. Awesome.

Oh for sure. Great. So I guess I'm going to be giving uh I guess a presentation on lean client architecture. Never done this before but how hard can it be? Uh so I guess going on to the agenda.

Uh some like I guess quick drop notes of what I'll be going over is like uh like the lean road map context. uh what are we trying to achieve with this? What are we trying to change with client architecture? Uh DevNet history uh how we've been iterating over like the last year and last few months. Uh reams architecture, how do we take the spec and I guess put into an actual uh client we're testing on DevNets.

uh protocol execution path like what are we doing in these 4 secondond slots um how we're evolving in recent DevNet. So currently we're testing DevNet 3 and we're currently in the process of implementing DevNet 4. Uh why why do these like recent changes matter to implementers and why are we doing it and then like we can possibly do some discussions if we have uh extra time. So uh why lean consensus exists? So, uh I believe it was over, yeah, around like a year and six months ago, uh Justin Drake, one of the uh one of the main researchers at the EF, basically had this idea of what if we could basically uh get Ethereum to this optimal state uh with threats along the line such as like quantum computers.

could we get Ethereum to the state where it's like stable and it wouldn't have these looming threats, but also like over the last 10 years of Ethereum, we also got a much a much better idea of what we want from the protocol. So, could we design like this optimal protocol and over the last year like how we thought of this and like the movement has changed over time. Uh for example, originally it was called Beam and then there was like a potential lawsuit. So we changed it to the lean chain. Uh where originally beam was quite focused on the consensus layer.

It moved to this like idea of a lean Ethereum where

Sorry to interrupt. Can you just click on the slide? Yeah. Now I think it wasn't changing the slides. Yeah.

Yeah.

I wasn't sure if you were speaking on the same slide. It was just on the first one. Great.

So maybe we are seeing the different version. Now we are seeing the the wine exists. Before we just saw the intro I guess you were sharing not the presenting presentation but this window. Yeah. U go ahead.

Yeah. Sorry about that. I'll just share this. Uh it should be fine. So uh so the idea became like what if we could simplif simplify Ethereum.

Uh one of the benefits of this alongside like securing Ethereum in a postquantum way is the less lines and the simpler Ethereum is uh the easier is to like formally verify and audit which just builds confidence uh in this finalization layer which is Ethereum. Uh so a few concepts that we want to achieve in this like optimal or plann of sorts would be like fast finality PQ signatures we want to get ahead of quantum computers uh because once that is a thing it's kind of like a bust moment almost uh a ZK friendly path uh some of the technical decisions in the past don't work like aren't totally friendly with ZKVMs And then like how does this formulate into an actual client? Okay. So, uh current so our current focus is basically like I think I'll just skip this. Yeah.

So, uh so we started off in DevNet Zero and now we're at we're about to start DevNet 4 uh DevNets. uh DevNet zero was just trying to get clients working at all. Uh we took a mo modified uh three like three a three block like state finality implementation made by Vitalic. Uh we chose this just because we wanted to get something working. Uh there's talks to change our the consensus me mechanism we're testing with along with uh many other parts of the stack.

But originally in this devet devet zero it was just like can we interop at all just to get the ball rolling and then the ideology behind all the devets is can we make this incremental change. So through every single devet we can basically like benchmark where we're at and then make an incremental change. And the hope is that we can do these incremental changes really quickly and quickly iterate and learn from any mistakes we made. So going into DevNet one, it was integrating uh lean sig signatures. So it's like for the first time we're actually using postpon uh signatures for signing and uh verifying blocks which was pretty cool and uh testing that on a devet.

Uh the second devet was uh aggregating those postquantum signatures. So one of the challenges with postquantum signatures is often they're quite large. So to actually be able to put them in the block uh you need a s so in current day beacon chain you basically u validators on the chain they attest to the block with a BLS signature. BLS is very aggregable. But the question is how do we do this in a postquantum world and the conclusion we basically came to so far is using a very minimal ZKVM to basically aggre aggregate these uh postquantum signatures into a single proof which is reasonable to fan a block.

um which makes it a lot easier which makes it a lot more capable of actually scaling the network. So instead of us including every single P PQ signature in a block uh what we would do instead is we would uh propagate them on the network. Then an aggregator would aggregate them all into one signature and then we'd include that minimal signature in the block fairly similar to what uh the beacon chain does with BLS. As I said before uh DevNet 3 was turning this into a separate role. Uh so instead of the block builder being responsible for both the task of building the block but also aggregating the block uh what if we had these as different roles and I believe that there's a few few EES and research paths wanting to do this on beacon but the idea behind this is if we specialize roles uh these actors can execute on these roles much more efficiently.

ly. So, and then for the fourth DevNet is one of the problem with aggregating is we can only aggregate so many signatures per a second. So if we aggregate the aggregations then we could potentially have like n committees of aggregators at one layer and then at the next interval tick of the slot we can basically aggregate all those together and through that we could have a much uh bigger validator base than what we could support if we only had one aggregation layer. Um so let's say at one aggregation layer we can only handle 50 validators. uh if we have 10 aggregators uh aggregating like uh 10 committees of 50 people, you could see that you can include much more uh validators into the set uh which is very ideal if you want a decentralized validator set.

So what is reimproving? So, uh, one thing we're working towards is building like a modular node where it's very easy to switch out these different, uh, pieces. Uh, one of the reasons for that is because, uh, a lot of our work currently is, uh, do I have water? So, one of the core tasks is just making changes. potentially we would want to completely switch out the networking stack or the consensus stack we're testing with.

Uh both of those are research paths that are currently underway uh by teams at the EF uh in terms of research. So a real life I guess cycle of the client is we have the leanspec where we basically like decide what we want to do for the next DevNet and then we work towards implementing that in a client with the goal of interoping with other teams and then verifying if our expectations of the research of form reality. Um and then so we want to iterate through death nets fast but oftent times uh these changes are breaking. So trying to interop with like uh multiple teams has sometimes I guess formed like friction which is one of the challenges and then yeah I think that is good. So re at a glance if we like kind of break it into pieces is it first off we have like an like a CLI where we input all the validators we want to run for the devet.

Uh this could this for example this could be like a genesis checkpoint we want to sync to or it could be like the current genesis we're starting from. It will be like a list of all the validators to build that state into and CLI options so we can connect to all the other nodes running in the devet. Uh we have a store of all the information we need. Uh this can include blocks pending at test stations and other such data. Uh we have an RPC like you would see on the beacon chain.

Uh this is just so we can probe the node, understand it, uh build tooling to better understand the devets and debug things which is quite useful. Uh like the beacon chain, we currently have a networking stack which is uh almost identically the same. Uh we just gossip different topics. And for the request response we have uh like instead of a beacon block we're gossiping uh a lean block and that is per a devet we will have different uh blocks being used uh coordinating our node uh in re we have like a lean chain service which just processes the blocks it processes at testations it handles syncing so we have two forms of sync we're either forward syncing so we're trying to catch up to the chain or we're like syncing the present chain which is uh currently in since devet three and going on to four we have uh five intervals per slot. So if a slot is 4 seconds you break that up into five and then there's different jobs we do in each of those intervals uh similar to the beacon chain.

So basically like handling those and coordinating those. And then we also have a validator service which handles like proposing the block at testations and and it also handles uh creating like the aggregations depending on if that validator has those specific roles on that block. Uh and then to communicate between these services, we just have uh channels in Rust. Um which is pretty similar to channels in Golang. And I have no clue how uh seer zig implements that kind of thing.

So uh how do these services interact? So we have like our lean chain in the center kind of like uh coordinating these duties. Uh the validator service acts fairly independently. It's basically probing the chain uh very similar to the beacon chain. And then we also have our networking stack which is sometimes sending requests to our node or sometimes we're requesting things from other nodes to it.

Uh and then of course we have our store where we store blocks and we also have an RPC so us humans can actually tell what the node is doing. Uh a typical boot sequence will look like we're loading a config uh who depending on the config we'll either do the genesis path where we're trying to start the chain from the beginning or we'll try to checkpoint sync so we can quickly check catch up to the chain. Uh after that we basically like build the anchor. So like the genesis we're syncing from uh if it's checkpoint sync all we basically do is we take the information of a trusted node the same as the beacon chain would and we basically just create uh an anchor we consider genesis that we would sync from. So we have these two paths and after that we would spawn our node.

Um so the core state consensus model is you have like lean consensus at like the lean state at the top uh which would contain like all the core types uh like block like uh block block headers uh justified or finalized checkpoints uh the validator objects for example we then have envelopes that we would like send over the network and sign validator let's see validator records are just like store internally which we' bootstrap from the config uh and then we also have feature gates which I'll go upon later but creating devets there's different strategies that we might pick upon uh for example in rust there's feature flags uh but other clients also use branches to manage their development between forks. And there's also another route of generics which production clients would often uh use in scenarios like this. There's trade-offs to all and I'll go over them later in the slides. Uh so the lean chain service you could think of it as it accepts uh the processing of incoming blocks. Uh it accepts incoming transactions.

uh accepts like incoming like uh basically like checkpoints from other nodes. Uh and through that we update our internal image of the chain and we're also able to provide this information to us like researchers and developers through the RPC and then we also have like it also manages sync and such. uh the validator provides multiple service depending on the duties of the node which can depend on the block or the node itself. So for example on tick one uh in the slot uh assuming the validator is responsible for creating a block we would basically ask the chain service to create a block. Uh once we get that we would do all the signing required uh by our validator and we'd send it off to the network.

Uh on tick one if we are in a tester for like that selective block we'll we'll like ask the chain to basically like for the information we need to test to it the chain service and then we'll like vote and we'll send that to the network. And then on tick 2 if you're an a aggregator which is a special role that is opt into uh every block you'll basically like you'll read the block you'll read all the attestations you'll combine all the attestations and then you'll gossip that proof to the rest of the network uh so it can basically like formalize that block is valid and attested by uh a 23 majority of the network. So our typical networking uh path is we have like the lean chain service and we get gossips through the network, we get requests uh we get it it it receives like potential checkpoint sync information uh that we might need. And then we also have a message bus where the the validator service or the chain service might be like requesting information uh through these different channels. So uh conceptually uh it starts out with just a config which defines everything we need from the service.

Uh we create the service objects which manages those different like discovery of other nodes. Gossip uh requesting or responsing like blocks or statuses of nodes and then um routing these messages between the services. Um uh below that we have basically like a behavior which is basically like an implementation what like defines how we handle these protocols and then below that we have basically a lib P2P swarm. Um this stack is what you would basically see on any beacon node today. Uh one interesting note is uh currently there's in the work to have like an optimized uh pure pure stack just for Ethereum.

Uh and the the conceptual idea behind that is uh lib P2P is a generic framework. Um what if we could build a framework specifically for Ethereum? uh this stack is likely to be adopted by the beacon chain or whatever ends up or whatever it becomes who knows and also the execution layer. It's meant to be an optimized stack and potentially like our teams would be testing that and prototyping that first. So potentially we'll like completely swap these two layers out uh with something the uh EF uh P2P research team is working on in the upcoming months.

So uh in the earlier slides I basically like touched a few of the ideas of like jobs we do at certain intervals but can we I guess like formalize that so it's a lot more clear. So we have interval 0 1 2 3 and four. And what are the basic I guess roles or priorities of each of those intervals? So an interval zero would be proposing a block uh which would be done by a validator what was selected on that block. Similar to the beacon chain we would have an at testation interval an aggregation interval.

uh we would update our targets and then we would also like intake the attestations at the end. Um potentially we'll also add uh an interval for like recursively aggregating the uh aggregations on DevNet 4. Uh but this one basically outlines the basic idea of DevNet 3. And these ideas also should map fairly well to the beacon chain as well. So if we are the proposer, how does that kind of look?

So the slot starts uh we our validator service requests the chain service to like hey build a block. Uh the validator service then gets that back. We sign and publish the block. uh that propagates through the network and later uh that's attested to aggregated and we basically have a new block added to the chain. Uh if we're not the proposer, well then currently in all our devets, every node acts as a validator.

So what we basically do is we receive the block, we verify it and store it. Uh we attest to it at interval one. uh we gossip our vote to the network and then after that the aggregator aggregates that all and shares the proof to the network and then we formalize that finalize we formalize that validated block onto the chain and how would this look if we were the aggregator? Well, the aggregator watches the subnets for votes. Um, in DevNet 3, that's basically like one committee, but in the future, uh, like the network would be split into multiple subnets.

Um, it basically gets all the votes for its committee. It builds the aggregate proof and then it uh gossips it to the network and then the all the nodes on the network would like up update their like head target and like the safe target and finalization target. So fork choice and aggregation. Uh so fork choice uh it tracks the blockchain. Um it decides what is the safe target.

uh it basically determines like what is our what is like the weight of the votes for each block. Our aggregation path is basically like basically like counting all those votes building it into one aggregate validating that and then pushing it to the network. Uh the goal is for uh the goal would basically be for like specialized roles to be more common throughout the network. Uh where currently the beacon chain is very uh singular. I guess we do have validators and we do have uh block builders.

Uh over time that should just be more enshrined in more specialized roles uh dedicated to special parties who can best handle that. And then architectural lessons. Um many of the lessons and the ways we're building clients has been learned from the beacon chain. Hopefully we can iterate and like figure out good ways to solve these problems so that like when it is ready for production uh we basically have like a good heading in how we should uh solve and design like the code and yeah research behind that. So um I've talked a lot about DevNet 3 and DevNet 4 but uh to be very succinct uh DevNet 3 uh signed blocks include the proposer at the station a single basically every single validator has a single a single key and then older proposers and then it's like we basically include like the aggregation proposal like into the final block.

So it's a lot more compact than DevNet 2. And then in DevNet 4, we're basically making it so the block container is standalone. We're separating at test stations and proposer keys. um block route. Yeah, block proposers will sign the block the block roots and it's basically just a cleaner path uh which will allow us to achieve recursive aggregation on that dev.

So why did we so for a lot of the lean clients we're like the goal is to quickly iterate through these research concepts so we can try to form this like minimal optimal state and ship it to Ethereum. So why did our team choose separate branches to to architect this feature or no why did our team choose like rust feature flags instead of stuff like uh separate branches and generics like other teams sometimes have chose. So for separate branches one of the challenges you do is you're basic you're you basically need to ma maintain two branches for the lifetime of both those branches. Uh well at first it looks simple. Uh often times if you want a fix uh you'll need to port it between both and these branches will also diverge more and more over time.

So applying these fixes from either like upstream or fixes elsewhere become a lot harder to track. Generics are good and we use generics when we want to basically test between two different like uh cryptography libraries for example. But using generics this early on for different devets for example like for defying differences between the state uh is a really high cost. So uh that's often done in beacon chain clients because there's a lot of maturity around like the protocol but for quickly iterating on devets where we might just throw away the consensus layer code or the P2P code as a whole and rewrite it uh which currently there are research paths to do that. Uh generics are a really big cost when we don't know the future.

So, uh, Rust flags are really nice because we can basically have like one branch and we can basically be super explicit on what code will run on one devet, one code that will run on another, and then when we're done with an old DevNet, we can just basically like um, regex delete all the old code, uh, bump the the next DevNet to the to the default flag, and then we can start working on the other one. So it allows us to execute on these subnets a lot more quicker. Uh which is super nice. So where where does ZK and um lean VM enter the SEC? Uh so for this case for for the single validators uh we're using uh let's see uh I need to check the name quick because it's long but let's see.

So we're using hashbased uh like multi- signatures which basically this is like a hashing scheme uh which can take like any like uh sign like hashing fundamental for example in our case we're using Poseidon there's some work underway to switch like what version of Poseidon we're using uh there was sometimes talks of using like shot 256 but currently the belief is Poseidon is like the most efficient hashing algorithm to be done on ZKVMs so okay let me switch back to the slides so Each so each validator first attests to the block with this like hashbased scheme. Uh but then after that uh what we do is we basically aggregate it using a minimal ZKVM uh which the repo is called lean multisig uh but the specific package we use is uh lean VM uh which I believe uses but that's more of a researcher question uh I don't really uh work on that part but yeah so how does bream integrate This uh I was saying this earlier uh throughout the talk but basically the validator service basically handles like the signing of like these hashbig signatures which would be lean which is basically like you could think of it like a a tree where you basically just like create a ton of like Poseidon hashes throughout the tree and then you use a leaf of it to uh basically like sign a block which is like the most simple way you could think of it possibly and kind of a wrong explanation but it's good enough to understand that uh lean multisig is the zk the minimal zkm which these signatures uh the difference between these is basically like this is the main repo it has extra patches this is what we use directly and then like integrating ating it integrating this all uh into the client. So aggregation uh aggregation and attesting to blocks is done by the validator service. Uh this work is validated by the chain service and the fork choice store and yeah so and then we load the node with basically a proposer key and an attestation key which is basically just like the XMss based like tree we're talking about earlier. So um one of the key notes with like XMss or like leanig is you're basically pre-generating let's say like 8 years worth of keys and once you use the like the key once you can never use it again.

Uh so separating separating these into basically like two trees allows us to further optimize our usage of the keys and like also simplify our stack quite a bit. uh which is nice. Um what's been hard in practice? So I would say spec drift. Um we would finalize a spec but then one of the challenges is like we find like a breaking bug or we find a like a really big performance bottleneck which we have to patch and uh coordinating that change between at the start it was three teams, four teams, five teams, I don't even know how many teams are at this point maybe eight.

uh co coordinating that change between multiple teams and basically like getting them to the state where they have a stable image we can run on devet has been somewhat challenging. So an example of this is let's say we have a state container with n fields if we switch one field it totally like breaks interopability between the clients. So, we have had issues in the past where it's like one client uh didn't update on time and we started a devet and then it's like why is everything failing? Uh or even like one line could like totally break interoperability. Um so testing in reality is not always the easiest.

We build these specific uh fixtures and test cases based off like theory, but oftent times you don't catch ED edge cases unless you actually run the manual DevNet itself, which running into these problems can sometimes be hard to debug. Uh I I would argue the work isn't actually isn't always uh sexy. Like every DevNet, we're incrementally building on the last DevNet. The goal of this is to ship very fast. Uh but oftent times if like there's one misalignant between clients, it can be really confusing to like figure out where is the problem and identify that.

Uh we are working on tools like better block explorer so we can like visualize this but one line can totally destroy a client. So work that's a problem pre-existing clients have to deal with. Uh and that's also a problem that seems like it will always exist. So uh what I would watch out for is like the object model will DevNet 4 will the will the semantics we think will work in DevNet 4 will they work enough to do in future DevNets or will we basically like completely throw that idea out? uh unless we try it on a devet and get those numbers, we basically like we have we think it will work and of course we're always doing what we think is the most optimal way forward, but unless you test us on a devet uh you have no real backing, right?

So it's like uh like the researchers and some members of the client teams are like we really believe in this for DevNet 4. We run a DevNet. Maybe that pans out, maybe that doesn't. Uh one one constraint is like currently we have 4 secondond slots. Can we really generate all the proofs and like distribute that to all the validators around the world in 4 seconds?

Uh this can be quite challenging as currently even in the beacon chain for example Australia has problem getting at test stations uh gossip to them in time to like finalize the block. So that can sometimes be challenging and we're being quite ambitious here. Uh I wouldn't say we have like one for one devets with like mainet of course but we are doing experiments. Uh and then it's like how will these dedicated like aggregators will roles work out and like how will these duties like actually finalize what makes sense? That's another thing that will be answered with DevNets.

And then stability. Um, one of the problems is like, uh, are we confident in this DevNet or this change? Uh, for example, in DevNet 3, uh, that's been running for quite a while. We've been doing many iterations of that. But some of the problems is like um I guess with like a lot of problems you'll get it to where it will work to let's say 1k slots but then it starts breaking down at maybe 10k slots, 20k, 100k slots, maybe a million slots and it's like do these experiments actually work in reality?

Are they stable? These are all things we have to like watch out for uh as we're working. So I was talking about like client architecture tracks but I thought I'd also go over some research tracks uh because in the last EPF a lot of people who like worked with re were really interested in the research path and contributed to it. So I think going over those would be quite helpful. So for example like uh Poseidon crypto analysis initiative uh earlier in the dev nets we were using Poseidon 2 and what we discovered is it's not as uh quantum resistance as it was I forget who did the paper I think it was like uh ETH Zurich they released a paper recently where it's not as quantum secure as we thought it was.

So for DevNet 4 uh one of the reasons why it's delayed is we're basically like switching the back end of lean sig and lean VM to use Poseidon one instead. Uh which currently we believe is a lot more quantum resistant. Uh hashbased uh multi- signatures as I said earlier this is basically like if you have a validator if you're signing any object uh this is the scheme we're using. P uh PQ signature aggregation with ZKVMs. Uh this is a work in progress.

Um I would I would argue one of the biggest things this is focused on is like an optimization problem. Um well I list examples like SP1 or OpenVM. Lean Sig is as simple as it can possibly get for our specialized case and I believe that with the like with the signature scheme scheme for lean synake which is basically like this above that we were confident with uh once we once we set lean BM to use that configuration we're only able to get around like 50 signatures per second uh with our like expected parameters for the cryptography. So it's like hopefully through like regressive aggregation and having a lot of aggregate committees uh we could boost the validators numbers up to like something we think is reasonable for decentralization and then formaliz uh formal verification. Um, as I said earlier, one of the goals with like the whole lean effort, uh, there's a lean execution effort and there's a lean consensus effort is just simp simplifying the critical path so we can verify Ethereum secure, uh, the more complex the critical path is, um, the more wary we have to be.

So having a simpler critical path for Ethereum is just more I guess you can mathematically verify it's security to a certain level. I believe I don't do formal verification but I guess that's nice for people to sleep on. God bless. Still other tracks is uh peer-to-peer networking. So there's pushes for like gossip sub 2 and how how do we make like 4 secondond slots work with like a million validators which at this stage who knows if it's possible and as I said earlier there's also efforts to like fully replace lib P2P with a custom stack optimized for Ethereum's use cases.

Um, there's a lot of work there and I guess if you guys are going to like ECC or ETH Brussels, there's probably a lid P2P day where you can learn a lot about like networking concepts like that and also like the basically like the state-ofthe-art gossiping mechanisms people are talking about. So, I'd recommend you going to those workshops. And then a tester proposer separation that's been talked about a lot. Uh could we basically prototype that in lean? Um that's something we're looking to into.

And then fast finality. Um a lot of these research paths are fairly complex. So having a test bed we can quickly iterate on with like multi-client dev nets is I think very beneficial for gaining a confidence for mainet uh which is very cool whether there's a lean fork or it's incremental upgrades of the beacon chain uh I think this work is really beneficial so I guess like some questions that you might be asking is like which boundaries feel stable enough to standardize across the clients right now. Uh I would argue probably the only thing is super fundamental things like SSC which is basically a serialization scheme. Uh other than that like there are talks of us potentially changing the hashing scheme from shot 256 to Poseidon to make that even more ZK friendly.

So honestly, I don't even think anything's stable enough to like say it's like we're going to keep it for like 5 10 years. Well, the initial devets are built off a lot of like the stacks and technology of beacon clients. Uh all of that's up on the table for like research and potential improvement. As as I said earlier, one of the goals was creating like a concise and optimal platform. Well, that is quite an ideal goal.

I think it's quite noble. So, where should proof generation live? Uh should should your watch be able to generate a proof? Uh should it be in some validator loop? Uh who should be responsible for this?

Should we just offload it to some like super warehouse like a supercomput? That's up for debate. Uh I guess currently block building's kind of like that. But for lean, one of the goals would be that like a smartwatch could validate. And then what would you optimize next?

Lency. Um, so for this it would probably basically just be like I guess fully going in into the like recursive aggregation path and seeing like uh how many validators we could scale this to uh while maintaining our goals of like being postquantum secure to some like n cubit. I think like right now we're targeting 128. Uh if this architecture had to survive real operate tomorrow, would you what would you change first? Well, uh we're so far from that that I guess that's not even a real question.

So, uh and then for the reading, uh I recommend people to look into leanroad mapap uh.org. Uh it was made by the ring team and it basically has like everything you could possibly need to get up to date whether that is research or learning about lean as a whole. Uh joining like the telegram to participate in conversations and join devets. Uh it's open to anybody who wants to join.

Uh I guess as like the founder of the EPF said uh his name was Piper. He was my mentor originally. uh he basically said like the doors are like like laughably wide open or something. I'm sure Mario can correct me on the exact quote, but it's like the doors to participate in Ethereum are like ungodly open. You just kind of have to like show up.

Uh for RE, if you want to like try to run, try to run a DevNet, we have like a quick start guide and we have some like Cly option documentation. Then if you want to look into our s source code, it's at our GitHub here. And then yeah, I believe that is the whole thing. So I will close this. Yes, thank you so much Kobe.

And uh yeah, Piper uh I think he used to say it's comically wide open. Like it's so easy. You don't have to break into the door. You don't have to try to unlock them. They are just so wide open.

um uh as yeah as one would uh just want to work on anything out there from different domains for the Ethereum protocol. Thank you so much Kobe. Uh we have bunch of questions that we collected in uh the chat here. Let's get over those in next like 10 minutes. We have 10 minutes to go.

So I think the perfect timing right now and we still have everyone here. Uh the first questions go back to the network uh part um or maybe uh actually like there is the first one was uh about a devet cycle and now like there is a definite cycle which is uh just like the next hard fork sort of cycle where new EIPs get like in each devet we add a new EIP that's implemented and and tested like cross client. uh but maybe there it was more uh you could talk a bit more specific about like the devets that you are doing within lean which are separate from like the current core development uh but as your own prototypes like what sort of like devet testing you do and what's the process there

yeah oh so for sure so uh currently all the I guess devets are coordinated on the lean athereum/pm repo on the lean athereum /pm repo and the lean ethereum uh lean

recording has stopped

uh oh okay uh so currently all the teams are working on the same devet so like we all coordinate on calls on tomorrow on Wednesday on like what are our thoughts on how everything's going and through that we basically decide what we're going to do next and then work is done on basically like updating the spec and also create like a formalization document of like what are our goals and what are our outlines in the project management repo. Currently all the teams are working on the same devets. Uh sometimes there's ideas of maybe it would be worth of working on another devet in parallel uh depending on what is happening. Uh currently all of them have been sequentially just due to the work. But yeah uh right now there's no like formal e process.

It's more like oh do we think this is like is this the next most important thing to like achieve our goals and then we just like spec it and then implement it across all clients and then we're like let's run it and see if it works. And then like a lot of the time it just totally fails and then we debug it and fix it and then we get our numbers and then we run it back and do the next biggest thing we can think of.

Awesome. Thank you Kobe. Um so yeah there was the part uh the question about networking uh like whether there is this something specifically designed for Ethereum. I know that like we're talking about the peer-to-peer uh but maybe what are their like what my question I would reframe it a bit maybe what are the uh like peer-to-peer changes uh compared to the current consensus or uh how we how we make the peer-to-peer more lean uh what are some fundamental uh changes if anything

uh for sure so uh like just to preface this uh like lean P2P or like P2P2 for Ethereum, whatever you want to call it. Uh it isn't my specific domain, but basically the understanding of it is currently one of the biggest bottlenecks in Ethereum is efficiently transferring like data between nodes. And this is one of the biggest bottlenecks from like shortening finality or shortening the slot time is it's like can we reliably get all this data to all the nodes on the network. So the gossip sack and the tech like is pretty generalized. Uh and it was built for I believe like what what was it like interplanetary file uh interplanetary file system like IPFS which is like basically like a DHT where people just share files.

What if we use like the most modern research to basically build like the most efficient way to like transfer these uh blocks and attestations between nodes uh to shorten these to shorten the like slot window basically. So yeah, instead of using like a generalized framework like lib P2P which is used by multiple protocols building one optimized for our use case.

Awesome. Yeah. Thank you. Um, so that was the question that aims also uh hold up and uh okay where do the ZKVM proving stages fit into the lean client? So going back to the stages there are the proving stages the biggest portal

are the so current currently I'd argue it is the biggest bottleneck cuz for each validator creating its attestation to the block that can be fully paralyzed over the entire validator set but currently creating like the aggregate signature with our like minimal ZKVM which is like lean VM. Uh we can only do like 50 signatures per second last I checked. So we we are playing schemes of like having like an aggregate of that. So it's like have like 50 aggregators create an aggregate and then aggregate that again. So you have like I guess like 50 * 50 each which is like isn't that just 50 * 50 but one of the problems is we we don't want to like compromise on decentralization.

So it's like I I would say it is one of the biggest bottlenecks and current research challenges that we are facing. So 100% Okay. Um so uh there was a question uh about the equivalent of execution layer maybe uh for more context if folks haven't uh looked into the lean road map. What's the equivalent of the execution layer in the lean upgrade uh or these updates are meant for CL only? Uh so currently what I'm working on is lean consensus uh for the execution layer.

Uh I don't believe we're going to be like implementing new clients. Uh my current understanding of the goals for lean execution is how like how we could possibly like simplify our current execution layer. uh but also like like basically have a GPU farm where you could create a ZK proof of like verifying the block so that like low-end hardware wouldn't need to do that themselves and then people who want to prove the whole block with their hardware uh can do it. So it is a bit of like I guess a different route and that route is more of like fun I guess like holding competitions for basically like ZKVM teams such as like SP1 risk zero. Uh there's a ton others and also running things like I forget what the website was but it was like basically like how fast can we prove a block in Ethereum and it was basically like every ZKVM team uh tried to like prove every be current day beacon block and in turn execution block in real time.

So stuff like that is more of the like lean execution side of the whole lean effort. Uh where the lean consessant effort is a lot more of like uh trying to figure out how we could like I guess postquantum the consensus layer if that makes sense. So it's like different tracks basically.

Yes. Different parts of the protocol and uh yeah this is the consensus in the current implementation of lean which parts of the specs still feel accidentally complex rather than fundamentally necessary and do you think those will get simplified at the protocol level or just absorbed into clients over time? So yeah, how do we feel about the complexity of lean which is ironic there?

So I guess we could kind of like break this into different sections. So in terms So in terms of something like cryptography often that's done by like very specialized cryptography teams uh at the EF or funded by the EF. Uh sometimes it's a mixture of both. So for example like uh the XMS research has been done by the EF. Um so like lean sig lean VM all that research for doing like postquantum signatures was done by them.

these researchers uh who also like implement these clients also like work on optimizing these. So the the same ideas apply uh from the beacon chain where like these specialized teams will build these very audited libraries that clients can use. So from our angle we don't have to deal with a lot of that complexity. Uh I would say a lot of our complexity would probably be like the networking stack. uh in terms of like fork choice and state stuff, a lot of that is just like optimizing us it.

So I would argue the most complex thing is like dealing with like the P2P stack in a generalized framework such as with P2P potentially like with like Ethereum P2P so to speak uh that will become a lot more simplified. Uh but there's always the challenge of like P2P building a really good P2P protocol is really hard. So like properly debugging that would then cause like all these new problems of then we're testing like 10 different ETH P2P implementations against each other. So, I think we're probably going to avoid that now just because like the complexity of testing a new PP stack is so high and we're just going to focus on like the complexity of like basically like in Oenheimimer you had like Oenheimer who's like this is theoretically possible and then you had like the research team where it's like we just smash two atoms together. Uh I'm on like the team like yeah we can split an atom and like the research team's on that side.

wacky analogy, but hopefully that answered the question.

Awesome. And one last question from Lee. How long does it take to generate the public key of the XMSS uh signatures?

Uh so clients can choose how many I guess. So I guess you have like uh so you have like your public key and then you have like a a leaf that you would sign this like a block with in the tree. So generating like proving a block can be done like super quick in like no time with no CPU. But generating these public keys uh you basically would decide like in how many years would you want to refresh these keys or generate more? I'm assuming a lot of people would want to generate like 10 years worth of keys and then you would basically need to run your your like M1 laptop for like 10 hours and then you wouldn't need to worry about that burden for 10 years.

Uh so it's basically just like scalable depending like how often you want to like refresh your keys for your validator. Uh it could be like as quick as a minute but then like you're going to run out of the keys you generated fairly quick.