Post Quantum Lean Ethereum | Justin Drake

recording is on.

Okay. Very well. So,

Mario, can you still hear me?

I lost Mario. Is anybody else?

Oh, I see. We lost Mario.

Yeah. All right. Uh let me just make sure that recording is still on. So you're free to uh go ahead and get started, Justin.

Okay, perfect. Thank you, Josh. Um so yeah, today I'd like to give a mini brain dump on on postquantum. Um and yeah, feel free to interrupt any time. This is meant to be more of of a discussion and a Q&A.

So just to set the scene, the way that I think about it is that there's the three layers of the Ethereum layer one. There's the consensus layer, data layer, execution layer, and each have to be separately upgraded. So we have BLS that needs to be replaced at the consensus layer, KCG at the data layer, and ECDSA at the execution layer. And within the execution layer, I would say there's two subpros. Um sub problem number one is what do we do in the short and medium term?

Um how do we give optionality uh to people who want to migrate as soon as possible uh to a postquantum wallet? And then there's the endgame uh which is the the longerterm solution. And one of my core thesis since you know a while ago is that for the endgame we're going to need protocol level support. And the reason is that if we were to just naively swap out signature schemes, for example, swapping out ECDSA with something which is postquantum secure, um we're going to hit uh a bandwidth bottleneck extremely quickly. It's just not sustainable, not scalable.

And uh to give you the numbers, an ECDSA signature is 64 bytes, a public key is 32 bytes. Whereas if you move to um N standardized postquantum schemes, the smallest one, the most efficient one is called Falcon. And if you configure it for the the lowest security level, which is level one, um you're going to get 666 bytes, which is you more than 10 times larger of a signature than than ECDSA. And so really one of the the big motivating uh research and development uh problem that we've been you know working on for a year and a half maybe a bit more than that has been uh has been signature aggregation like how do we take many of these very big signatures and squish them together into into a single proof and we have the luxury of being able to do this in Ethereum because we're in a batch setting right we have a single block which has multiple uh transactions and so it kind of makes sense to batch them because they're literally packaged as as a batch and you know we also have the luxury at least at the execution layer to have a block builder and to have you know ZKVM stuff where you have a prover that's like reasonably powerful and can do the the the the aggregation for you. So without the aggregation again I think it's a non-starter because we would go from 25TPS to something much closer to 3TPS.

And similarly for all of the other blockchains if you take Bitcoin which is currently at 3TPS per second 3TPS you would you would go down to something much lower closer to you 0.3 or 0.5 or that that kind of uh ballpark. So um the aggregation story starts at the consensus layer. Um and the reason why I looked at the consensus layer first uh was partly because I had this this this this beam chain uh proposal but also it's where we have the most amount of signatures floating around.

So just to give you the numbers here, we have a million validators. They're each making an attestation once per epoch. There's 32 slots per epoch. So that's 32,000 uh validators or testers per slot. A slot is 12 seconds.

So you divide that by 12. 32,000 divided by 12, you get over 2,000 signatures per second. This is an insane amount of of signatures that need to be uh processed. And there's certainly no way that we could do it without aggregation. We even have today aggregation with with BLS.

And so you know how can we uh solve the consensus layer and and basically hope that whatever technology we develop can can be used at the execution layer and maybe also at other layers like like the data layer. Um so one of the uh kind of starting points was okay what do we have in terms of options for for aggregation and long story short there's only one option the the the only option that we know of that is you know sufficiently flexible and and uh and efficient is to use uh snarks specifically postquantum snocks that uh you know could be hashbased or or latisbased Um in practice almost everyone nowadays uses hashbased knocks. Um there's a few kind of frontier research groups uh including Microsoft and and Jolt that is looking into into Latises. uh but you know primarily the the the industry has converged towards to towards hashes and I think hashes are really excellent because at least for Ethereum because they uh you know minimize the amount of uh security assumptions that you're making you're just trusting a single hash function and to a very large extent um blockchains already trust hash functions as as a song cost we use it everywhere in Merkel trees and in in in blocks and etc. So yeah, from a security standpoint and from a performance standpoint and a flexibility standpoint, we've gone down this path of aggregating signatures with uh with with hashbased knocks.

Now one question you may ask is what scheme could we use as the onagregated uh signature? And um here we have um basically two classes of of of signatures um that are you know most trusted. So there's actually the the same the same families that we have at the stock. There's the hashbased stocks and the latisbased stocks. Uh NIST um has standardized two uh latisbased stocks.

There's a Falcon and Delithium. Um, Delithium is kind of more friendly to use and uh, you know, it's easier to sign. Uh, it's kind of very nice to verify. Um, and so that's the one that is it's also simpler. So that's the one that NIST is kind of suggesting people use by default.

Uh, but unfortunately, you know, it is quite large. It's I believe around around 3 kilobytes. Um and uh also it just so happens that it's completely unfriendly to aggregation. It's like the you know one of the worst uh you know options that you that you that you can think of. And so in our context you know that's kind of out of the question.

Uh then you can go through the list. There's another hash function called falcon. Um sorry signature scheme called falcon. And um here there has been some research in in trying to to to to aggregate it but unfortunately for various like technical reasons it's just very very painful uh to to work with. Um and especially if you want to be like NIS compliance you want you want to be using the the NIS compliance hash functions.

And so uh that that doesn't seem like a like a good place to be either. Um and then that brings us to the the the hashbased schemes which traditionally lit N list N list N list N list N list N list N list N list N list N list kind of have put out there for diversity reasons and kind of as a backup for for you know in case maybe latises break or whatever. Uh but this is not the the default suggestion because the signatures are quite a bit uh larger. And so um you know one of the key observations that we made is that for us if we're going to aggregate the signatures the size of an individual signature doesn't really matter so much uh because it it will only be you know gossiped and shared offchain um and you know in the context of the execution layer only in the meool and then uh you know you only have the the final aggregated uh snark that that that goes was on chain. So the in some sense the the main downside of hashbased uh signatures goes away once you have this this this disagregation and that really makes the the hashbased signatures uh shine.

So in in Liner right now we're making a massive massive bet. We're going all in on on on hashbased signatures both for the the the leaf signatures that are unagregated as well as the the snark that will go aggregate them. Now, if you zoom into the family of of hashbased signatures, there's there's basically two options. There's what's called stateless signatures which are the signatures that we all know and love something like ECDSA or BLS and those tend to be slightly bigger. So, you know, on the order of of a few kilobytes, think maybe 10 kilobytes.

And then there's um this other thing called XMSS uh which is a a a stateful scheme. And here you have roughly speaking a 10x improvement in performance. So the the signatures about 10 times smaller. They're only about one kilobyte. And the amount of hashing you have to do to verify a signature is also about 10 times smaller.

So you know about 200 hashes instead of of 2,000 hashes. And uh the question you might ask is okay why isn't everyone using these these these stateful signatures? And the reason is that they're kind of dangerous at least for for end users that are unsophisticated. And the reason is that they have this this security property which is that um every time you sign there's an associated counter like a non if you will and this counter should never be used twice. Um, and if you do, you know, sign two messages with the same counter, then then you're screwed.

You basically leave your private key. Uh, and then anyone can can empty empty your account. So, um, the the the reason why these these stateful signatures are, you know, especially attractive at the consensus layer is that this is actually a setting that we're very very comfortable with. when you set the counter to be the slot number, uh, validators today are not meant to be signing um, you know, two messages with the same slot number, otherwise they get slashed. And so there's a very very big disincentive to get slashed.

Um, and you know, there's there's a whole um, suite of of of tooling to prevent uh, slashing. So for example in software you have these things called anti-slashing databases which record basically the messages that you've signed and will make sure that you'll never sign two messages with the same slot number. There's also you know defense in depth for IND uh for for some of the more sophisticated um uh stakers that will have you know some sort of HSM or or hardware wallet uh to to to do the signing. And so that is you know one of the the key optimizations uh that that that we have to make the the the signature stateful. And uh one of the the recent outcomes from literally last week I guess is that we managed to get the size of these signatures uh with 128 bits of security under uh one MTU.

So an MT MTU stands for maximum transmission unit and it's the the the size of the Ethernet packet. Um like it's it's it's it's it's the the maximum size that you can send in one Ethernet packet without it kind of being broken down into multiple Ethernet packets. If you want to have a super optimized uh gossip um mechanism for for your leaf signatures, then have being able to fit the whole signature within a single packet is is is really cool and unlocks you know UDP based uh you know communication and and stuff like that. In any case, so we we we we got the the signatures under the MTU. Um so for IPv6 uh which has you know these bigger headers the MTU is uh 1,280 bytes and we got it under 1,200.

So you know there's a little bit of buffer to have metadata like the slot number and the validator ID blah blah blah uh in addition to to the signature and the whole thing fits fits within the the MTU. And um so that's on the on the leaf signature side of things. And really what we're trying to do from a performance standpoint at the aggregation layer is to aggregate a thousand signatures per second on a laptop CPU. Um and this is something that we have uh we have achieved basically. So we have this project called lean lean VM.

Um it's under the the the lean Ethereum um GitHub organization and it's a a minimal ZKVM um that is hashbased and that is specialized for verifying hashbased sign uh cryptography and uh it's uh it's it now nowadays it's you know with with all the optimizations that we've put in it's capable of of aggregating a thousand signatures per per second on on a laptop CPU. And and the reason why we're restricting ourselves to to to these uh laptop CPUs is basically for decentralization. So we're assuming that a small subset of the validators will be running on a laptop. let's say 10% of the validators will be running on the laptop and then they those 10% of validators uh will have sufficient hardware to assist uh the uh the aggregation altruistically. So this is you know very similar to what we have today where the validators altruistically help with with BLS aggregation u but instead of being nominated to be aggregators as it is the case today it will be permissionless.

So literally anyone can become um an aggregator. And this permissionlessness um actually comes from one of the superpowers of of uh of lean VM uh which is that you can aggregate aggregates uh even if there's non-zero intersection. So what does that mean? It means that if you have you know signatures A, B and C, you aggregate A and B into an aggregate aggregate one and then you aggregate B and C into aggregate 2. Well, you see these two aggregates have a non-disjoint intersection.

They both share signature B and BLS really doesn't like that. uh so so you can't you know aggregate AC across aggregates when there's um when there is an inter a non-zero intersection whereas mean VM doesn't care at all like you can you have a much powerful model for for aggregation and this allows us to have trustless aggregators uh that could just work independently without this kind of top- down coordination uh if if if you will so um we're we're in this fantastic position uh from the perspective perspective of of aggregation and the other key performance metric uh that we have for for lean VM uh is uh what we call 221 recursion. So if you have two aggregates and you want to build a meta aggregate you're basically doing um snark recursion and and here we got the the recursion time down to to about 800 milliseconds. Um so we're we're not completely happy with that number. We want to get it get it down closer to 250 milliseconds.

But uh yeah, this is ongoing work and the person who's leading this is called Emil and he's uh he's really doing a a fantastic work and we know from another project there's this other project called Plunky 3 recursion that managed to get 250 millisecond uh recursion time. So we we know there's like a proof of existence that it can be done uh and uh and we're relatively confident that that we can get there um as as well. Now, when uh working with SNOX, especially at the consensus layer, we want to make sure that there's like literally zero bugs because a soundness bug would be really really bad, right? Because you'd be able to um to fake someone signing when they didn't sign and then you can you can cause cause them to get slashed and you can eject validators. you basically have a lot of control over consensus if you can if you can fake these proofs and it would be it would be really really bad for for Ethereum if there was a bug in in in in lean VM and so our strategy has been to um make lean VM as simple as possible um you know hence the word lean so lean not only refers to the lean cryptographic assumptions just the hash function but also the the amount of code uh in order to implement it and the design of lean VM has six instructions um all of which are you know very natural so you have four simple operations uh addition multiplication a jump instruction and a memory instruction and then you have these two pre-ompiles that are slightly more complicated one is a hash so it's the the the pad on hash in this case and the other one is a a field element extension because you're not doing only mathematics on on field elements but you're also doing it on extension fields um which is uh you know these field extension elements are used in in the recursion which is why we have this this this pre-ompile but overall we want to keep things extremely simple and um the whole uh description of the lean VM verifier which is the the key cryptographic essence of it um is uh is on the order of a thousand lines of Python code, right?

So like all of the the the hardcore cryptographic complexity is is condensed in in in just a thousand lines of code. Um and that is a a fantastic outcome from a complexity standpoint. Now one of the things that we want to do as well in addition to keeping complexity low is to end to end formally verify uh the the the whole thing. And here we're in a really fantastic position where um formal verification has gone through an inflection point literally in the last few weeks. Um so in February uh AIS were able to build um formal proofs of of of uh of theorems that were you know on the order of a thousand lines.

Um and we actually had uh one of the theorems approved uh called the polyshock spillman lema in the context of of these hashbased snarks. Um but then you know last month in in March we had AIS automatically uh generate proofs that were hundreds of thousands of lines long. Um and that was in the context of uh of the the Fields metal result from 2022 the the optimal optimal uh sphere packing in in in 24 dimensions. So this is like bleeding edge mathematics and then AI over five days just produced this this proof that was half a million lines of code which is absolutely insane. And now we're seeing this this formal verification framework called lean for the word lean uh you know is actually colliding with lean ether theorem.

These are two different things as lenum and lean for um but actually the these two leans are very much symbiotic at least lean for is is helping is going to help leaner in in in a big way. Um, so what previously would have taken, you know, many months of of of human effort and cost, you know, hundreds of thousands of dollars to do will be uh will be a job that will that will cost maybe tens of thousands of of of dollars and and will be done in a matter of uh of of of weeks uh maybe possibly even even days. So this is the situation at the consensus layer and I just want to to pause to ask uh for you guys to ask question one thing.

Okay, go ahead. Yeah,

I'll just pause here.

You so much Justin. Um I think somebody just unblocked a mic by mistake there but um awesome. Thank you. Thank you very much again. I'm sorry about my internet moment ago.

Um Folks, if you have any question, please raise your hand. Feel free to ask or feel free to write in the in the chat as well if you cannot use your mic. But yeah, feel free to take the opportunity. And Lee has a question. Go ahead.

Hi Justin. Uh

yeah, happy to see you again and uh

thanks for the explanation. I'm happy to hear that the progress of formal verification. I'm just wondering like you mentioned there already some parts has been done. So I'm wondering

yes

which part is done.

Yeah. Yeah. Great question. So um when you're dealing with a proof system roughly speaking there's like three layers. Um actually in our case four layers.

So what are these four layers? At the very bottom you have the mathematical foundations. So here you have um you know in the case of hashbased signatures you have the so-called proximity gaps theorems that we rely on. This is basically very sophisticated uh linear algebra. Um and here I mentioned the the polyshock spillman lema which is part of of of proving you know that the mathematics is correct and the foundation has invested a lot in a library called arlib.

Um so arc is the arc and snark. It stands for arguments of knowledge and lib is library. So it's it's a library to prove that arguments of knowledge are sound. Um it's written in lean for and we basically have a proof of soundness that fry for example is is is correct and and like spartan is correct and were great. So you have these building blocks that we can now uh prove are are sound uh meaning you know that they have provably 120 bits of of of of uh of security in a cryptographic sense.

So that's that's good. That's the the the basic foundation. And then level two is the the end to end um proof system. So here uh basically you you you take all of the components together and you have what's called an IOP an interactive oracle proof where um you know you you have for example a memory argument this could be something like logup um and you have your PCS which might be were and then you have some like sub routines like like uh you know sum check or you know whatever it is um And you kind of stitch everything together in a in a proof system. And here we've um you know we've you know we've we've started making progress I already mentioned Spartan which is a a proof system.

We we actually use super spoton in the context of lean VM or actually a variant of it. And uh what needs to be done basically is to formally specify uh the the the proof system prove that it mathematically that it has the the soundness that we want and then prove that it it's basically equivalent to the verifier in Python that I mentioned or the verifier in in in the lean ISA. uh because we're we're taking the Python and compiling it to to to the okay so that's level two and then level three is um you know the so-called arithmetization of uh of the ISA. So in our case we have this super trivial ISA um and uh one of the the great news here is that we have uh done formal verification of of ISA size in the context of risk 5. So risk 5 is a much much much more complicated ISA than lean ISAF.

It's you know it's about 10 times more complicated. It has 10 times more instructions and each instruction is much much more complicated as well. Um and uh the good news is that we have already formally verified the implementation of SP1 hyper cube and uh openVM and then we're also working on uh on uh formally verifying the correctness of the pico arithmetization. So this is something that is very much under control because we've done it on on on much bigger systems. And then there's the final layer that needs to be formally verified which is the lean ISA program.

So in our case the program is going to be you know the aggregation program that takes multiple XMSS signatures and squishes them uh in into one and um it's possible this is where like most of the effort will will need to happen but there's a very recent project called EVM ASM. So this is an an implementation of the EVM in assembly uh in in wrist fiber assembly specifically. Uh it's it's by this guy called Yoichi who's been in the space for for over a decade. He took a hiatus but he's he's back and he's basically been um using AI to not only generate the assembly but also prove that it's correct. And uh basically a similar approach will will probably work uh for for aggregation of XMSS signatures and you know the EVM is much much much more complicated than XMSS uh aggregation and so if UC can do it for the EVM certainly we can we can do it um in our context.

So long story short, we've been able to to to do the formal verification in a much more complicated setup uh specifically for for the for the ZKVMs. And and really what we need to do is is reuse these techniques in in the simpler uh lean VM.

Thank you so much, Justin. Um Andreas has a question. Oh, you're very loud. I think your mic Andreas, can you can you try to uh hear?

We can't hear you. It's very distorted.

Yeah, sorry ma'am. Before we used to hear as well. Um

yeah. Yeah,

it's better now.

Yeah, it's perfect. Yeah, go ahead.

Thank you so much. So if I understood correctly your previous answer and you probably have already like answered my question but yeah I was also watching a few days ago uh a code like core devs had all layer 1 CKVMs and they were talking about that these EVM ASM project um where they were using like loom 4 for doing uh both the yeah like the op codes of the EVM and also the proving of that codes. So my question was if the link for was only being use it used in the EVM aspect of Ethereum of or if it was also used in link consensus but I think that the answer is yes because you was you were talking about um doing the verification of the um signature aggregation. So yeah, how my question is how is in in what ways are we using room for to do some formal verification in the consensus layer?

Yeah. So for high assurance software like Ethereum, lean 4 is the perfect match. Um

I just

Oh, sorry. Thank you. Um it's it's it's really an amazing match. uh and you know we've been wanting to do end to end formal verification for for a very long time but now we we actually reached a point where formal verification is so cheap that it's starting to eat the world and you know various people have this saying which is lean for is the new rust right in a in a context where um generating code is extremely cheap uh with AI the the bottleneck the the scarce resource is verification And formal verification is the best type of verification that that that you could hope for because it's it's automated. Uh you don't have to read the proofs.

You just have to read the the the fair statement or the the the the you know the the the claim that you that that you're trying to prove. Um and I I actually think that you know it's not just a firm that's going to be using lean for everywhere. It's the whole world is going to be using lean increasingly like right now um we've reached a point where um AI can prove one theorem per day like open problem per day. So um there's about 1,500 Erdos problems. Erdosh is like this very prominent mathematician where he would just like create lots of open problems across across his life.

And um you know just yesterday there was this 60-year-old open problem which was solved by an AI and um you know there was like some some genuinely like new mathematical insights that that that came from the AI. The reason why I mentioned Erdos DOSH is because every time an Erdosh problem is is is proved, the AI will generate the math paper like a PDF that is human readable, but it will also generate a lean for proof automatically. Um, and so now, you know, it's kind of taken for granted that if you're going to solve one of the other problems, you have to to to provide an accompanying a lean for proof. Um and uh you know I think the same thing is going to happen in in in in in other places. Um you know lean lean for was originally developed for mathematics and so it makes sense that uh it dominates there.

Uh but more and more it's being used to prove statements about code. So basically in in in in the ZKBM context that you mentioned EVM ASM um you have a description of the EVM a formal specification you have a a description of risk 5 also in infall um and then you have your your assembly and then your theorem is that the assembly is a faithful implementation of the EVM in risk 5 according to to these specifications. Um and then you might have like other auxiliary thems for for example you could have that your riskfi specification is equivalent to other specifications potentially in other languages like like rock or or k which are which are formal specification languages for which we we we also have um ev e uh specifications. Um but yeah, like we're we're entering a brave new world where everything will be will be verified. So not only will we right now we're entering this weird phase where all of the bugs are being found uh you know with things like methos uh but not only will we have zero bugs but we will also have a proof that there's zero bugs which is uh the the ultimate endgame for verification.

Yeah, thank you so much. It it is actually like actually incredible to uh feel that now I can prove that the answer that it did is correct. So yeah, I think what what you're saying is something like really big. Thank you so much.

Yeah. And um if you if you look at the the rate of progress of of AI, you can just draw some some some lines basically and extrapolate and It's quite plausible that by 2028 we're going to have all of known mathematical knowledge be formally verified. Um so um you know there's you know there's maybe on the order of a billion u lines of mathematical proofs out there or maybe like 10 billion lines uh of of proof. You know that's kind of an upper bound. Um, and you know, that's the kind of of of of task that uh soon the the AIS will just be able to to to to gobble up and and digest.

I don't know if you've seen the the documentary um on the on the founder of of Deep Mind. It's called Thinking Game. It's about Dennis Hassabis. um you know there's this like famous scene where you know they were able to solve the protein folding problem um using using AI and uh you know one of his colleagues says uh you know how are we going to present this to to to to the to to the world and originally they had this idea of an API endpoint where you submit your your your your DNA sequence and they would kind of give you the the the protein as a response and then one of the engineers said hey we have about 300 million uh known uh proteins. Why don't we just sequence?

Well, why don't we just basically fold all of them? And that's what they did. They just took all of the the known uh protein sequences to known to humanity and just folded everything and provided that that as a as a free resource. And we're going to do the same thing for all of the mathematics uh very very shortly. And then eventually we'll do the same thing for all of code.

So we're kind of kind of as a humanity we're kind of going through uh through these checkpoints and and milestones and uh we're living in a brave new world where you know you're witnessing this on on a month-by-month basis which is crazy.

Yeah, I haven't seen that paper but I will take a look. Thank you so much. It feels very exponential like uh thinking about how uh beacon chain uh formal verification before it was deployed was happening for like long time and it was only partial in the end like wasn't uh wasn't as much useful based on how expensive it was to like we are now on completely different spectrum. It's incredible. um also for like DeFi security.

It's very exciting, Justin. Like, thank you so much for diving into that. And but the the my favorite part is just the coincidence that like the lean and lean for language is just get so useful now when we have lean ethereum like uh it's yeah it's a great coincidence.

It's actually not a complete coincidence in the sense that the reason why lean po is called lean is because they follow the same principles as leaner. They want maximum simplicity and they want the so-called kernel uh which is basically where you have all your axioms and you have you know the deduction from from previous statements to new statements. Um so that's the the core reasoning engine if you will. Um and in in lean 4 the the the core reasoning engine is is is very very small and it's actually small enough that there's multiple implementations. So there's uh one in C++ I believe one in Rust and and there's also a recursive one in lean for itself.

Um and you know when you work with these these formal verification frameworks you basically have this notion of a trusted codebase which is you know the the kernel if you will. Um and not only is the kernel very lean and small uh but they they've adopted the same strategy as Ethereum. So they've leaned on diversity to hedge against bugs in in the kernel itself. Uh which is uh which is a cool coincidence.

Yeah, of course. I mean naturally like I have the best engineering principles and the uh uh approach that makes the protocol strong is like what what benefits from it. So that's uh uh that's great to see we have the the similar approach there, not just a coincidence. Um cool. Uh so we talked about the consensus before.

Uh do we want to move further or do you guys maybe have some more questions? Something quickly to touch on?

Uh we are like almost Okay. Uh we have a we have a question so let's read it quickly as well.

Uh hello Justin. Uh so I wanted to ask you a question that how will light clients will be with uh an environment of formal verified Ethereum

light clients. Okay, great. Um so the the the good news is that the best type of light client that you could hope for is snark based. uh and we're basically stockifying all all of Ethereum and we're also formally verifying this notification. So really what what you'll just do is uh just verify these you know one snark per slot for example uh and then you know that that's that's basically job done at least for the execution part of things.

Uh and then there's also data availability where you have to do data sampling and this is this is kind of the endgame that that Vitalik envisioned quite a while ago where as a as a light client you just verify a snark and you do a little bit of data sampling and then and then you're done. Now um at the execution layer we have uh ZK EVMs um and the direction that we're going in in the short term is to have a diversity of ZK uh EVMs uh something like five of them I the exact number hadn't been really settled um but the interesting thing here is that they would be enshrined meaning that you don't today as a validator you have a choice as to which uh you clients you run in the future there'll there's kind of no choice at least on the the ZKVM uh part of things. So it's kind of dictated by the protocol. Um and you would uh you would have some sort of a threshold. Uh so if three of them three out of the five for example agree that's your source of truth uh as to what the the canonical uh Ethereum uh is.

And at the at the consensus layer, it would be a similar thing, but it would be non-enshrined. So at the consensus layer, there would still be, you know, optionality as to which clients you run. So you could run, you know, Prism or Lighthouse or whatever it is. Um, and you can also choose your proof system. Um but eventually over the very very long term what I expect might happen is that we're going to move towards um something which which I call um canonicalization.

So it's kind of a stronger form of enshrinement where there's only one that is picked. So once we have um sufficient performance uh and we have entered for modification of of of the ZKVMs we can just pick one and and and and call it today. Um and and we can probably do something similar at at the consensus layer. So, in the endame endgame, if you will, the true end game, end game final, um you should just be verifying one proof and it's kind of dictated by the protocol and it's like provably secure and and and that's the definition of Ethereum and you're done.

Yeah, thank you Justin. It's really uh great to have like a native light clan basically like if everything is ZK and it sort of just works compared to like SPV approach or some like crazy light CL protocols we tried three years. I mean

uh Andreas has another question.

Yeah. So what you would was saying is that uh in that case we will have like only one client implementation and we can formally uh verify that client implementation and we will use that one.

Um so yes and no. Um the part that would be canonical and enshrined uh would be specifically the state transition function. So that is um about 10% of a of a traditional uh code base of of a full client. What a full client will do in addition to verifying the state transition function is do all sorts of ancillary things. So for example, it might maintain the mempool.

Uh it will maintain a database maybe for the state. Um it will have a whole peer-to-peer networking stack. Um and uh you know it will maintain the fork choice rule and then blah blah blah blah blah like it will do all sorts of of other ancillary stuff and here fundamentally you can't really enshrine it. It's it's fundamentally off protocol and here you we would still have diversity. Um it's just like the the core consensus kernel if you will um that that would be uh enshrined and canonicalized

and I I like the term Mario native like client is pretty a pretty good term

and yeah I don't know if this is off topic but it is impossible to formally verify a full client. um yes and no. So the thing is that there's like all sorts of difficulties. So one of the difficulties as a when when you're developing a client is that you don't know which environment you're running in. So for um for the the state transition function we can have a canonical ISA.

So you could have for example risk 5 being the canonical ISA or lean ISA being the canonical ISA and that's kind of fixed and you can think of it as a as a virtual ISA if you will. Uh but when you're running on real hardware, you know, there's like essentially an unbounded family diversity of hardware. There's like x86, there's ARM, and you know, there's a AVX, and there's, you know, all sorts of, you know, flavors of of SIMD, and then, you know, if you're dealing with with with Snops as well, there's the whole like GPU proving aspect. So you you have to work with CUDA and uh and and and kind of capturing all of this complexity is is is is very very difficult to do. I mean in principle it is possible where you know every time a C a CPU vendor uh you know produces a CPU they they have a corresponding like lean force specification of you know how the CPU works and then you somehow maybe you know when you download the software you you make sure that the ISA is kind of is compatible with the bite code or thing, but you know this this is like very very futuristic.

Um it it could potentially be done.

The the thing is that when you zoom out and you ask about diversity, traditionally the number one answer was uh security and I think we'll be able to large extent to to move past that. Um but the the other answer has been uh governance and I think here it is healthy actually to specifically you know embrace the fact that there are some things that you can't easily formally verify because as a second order effect you you you kind of get a more robust social layer and governance that is that is harder to capture. Um and then there's there's a third aspect actually which traditionally I have uh underrated um which is innovation. So what we've seen in in the ZKVM context is that the innovations come from different teams. So there's roughly speaking five teams or you know maybe a bit more that that uh innovate meaning that they they come up with these new ideas to make the ZKVMs faster and the ZKVM teams all copy each other because it's all open source and uh and they all kind of it kind of lifts all boats and it's a beautiful thing to see and this has led to basically 10x improvement per year for the for the last you know few years which is which is mind-blowing And in the context of the ZKVM, we want to increase the gas limit by 400x.

So we're at 2.5 mega gas per second right now. We want to get to 1 gigas per second. So that's a 400x. And in order to get this 400x, we're going to need a bunch of innovations.

And so it's it's kind of strategically valuable to uh keep that that diversity purely for for for innovation purposes if not for also for the benefits that we get from a from a security and a governance standpoint.

Thank you so much. Now I get it. It's like technically possible but uh really really hard and have has some implications about yeah innovation. Thank you so much.

Exactly. Yeah, I would say that maybe like you know on a different level or more in practice like we have very robust testing suites like on the whole client level like we have uh very strong uh testing tools that are generating tests from specs right and those specs are will be uh formally verified. So uh like the approach there to make it uh more usable in current time like it's it's going to be applied to

uh the tools that we have. Yeah. I mean one note quick note on the specs. So if you look historically at Ethereum specs, the very first one was the beacon specs. Um and this was kind of put in place about you know six years ago or so and you know it was the very first time that we had an executable spec and you know that was a big milestone um in terms of of maturity but we made a lot of mistakes in the way that the specs were were set up.

Um it's just very difficult to work with. And then came a second generation of specs for the execution layer. Um that you know the with eels and the steel team that um and here we kind of got a a step increase in the usability and and and and the usefulness of these execut ex executable specs. And now with the lean specs, uh, which is basically a rewrite of the the consensus specs, we're we're kind of going to the next level yet again. Uh, and and the the the way that we're differentiating ourselves is by making the specs AI first.

Um, so, you know, we have like skills embedded in the specs. Uh, we're assuming that the specs are going to be machine read. we, you know, we have all of the links to the relevant documentation and all the right context and we make sure to scope things so that we're we're not polluting the AI context with you know unnecessary stuff. We just give them the the essence of what's going on. And we're basically assuming that uh you know the primary consumer of those specs in some sense is is is AIS.

And one of the upshots here is that the barrier to entry to building a lean consensus client is extremely low. And this is the reason that we have over 10 clients now that have uh that have joined the the the the development and the death nets. Um so we have the the the OG uh beacon clients. There's you know five or six of those and then there's another 12 uh lean consensus clients. there's a total of 17 clients.

Um, and so we're we're taking diversity to to to the next level at at the consensus there. Um, and one of the interesting dynamics is that the teams are very very different. So in the OG beacon teams, you're looking at roughly 10 people per team. Um, whereas in the newer teams, you're looking at roughly two people per team. So you know the the lean meme kind of uh applies at the social layer as well.

we have these lean teams um and you know what I predict will happen is that um you know because most of the heavy lifting will be done by AIS which will be you know the world's best coder actually multi many times better than even the world's best coder there's like no no real like technical value ad and so these team leads if you will will be uh in addition to being like sheep technical shepherds they will also be like community leaders and they will participate in governance and they'll be you know at the momentic layer in some sense um and so I think the nature of of client teams is going to to to radically uh shift Justin uh that's very uh well exciting but interesting specifically for the folks here who are looking into um uh the EP PF the fellowship now and actually starting to contribute to uh well all kinds of Ethereum infrastructure whether it's the current clients or the future clients the um uh the lean client repos um

and one thing that I would say here is that one of the key value ads of humans will be friction like we're going to be slow and dumb and that's going to be valuable why is it valuable because we basically want Ethereum to be as robust as possible when we want to enter this maintenance mode and you know ultimately oification and we want to you know be paranoid and verify everything and so really the key technical skill that will be valued in the future is you know can you sanitize the the lean for specs and can you make sure that the AI is not taking any shortcuts that really it is proving the theorems that you want to be proved um and you know you want to assisting in in in ways that are uh you know ancillary to to to the core development. So, you know, for example, you want to help with uh I don't know, like uh documentation or with marketing or making sure that um there's strong infrastructure to to to to avoid uh you know, fishing attacks or or whatever, you know, or maybe uh you know, supply chain attacks or what whatever it is, your your your role will will change quite dramatically.

Yeah. prompt injection in in this case, right? Uh sort of social engineering for AI. Um yeah. Okay.

Thank you so much, Justin. Uh maybe like to elaborate uh a bit on that like uh so for people here who've been learning about uh lean in past couple of sessions uh and have a good overview like we already saw some specific projects like uh where they can contribute but uh there is so many of these different clients and so on. What are your tips maybe for somebody who uh wants to find a good place where his uh uh sort of input his work would be valuable uh when starting to look across the different clients, different parts of infrastructure or uh yeah uh in in lean in Ethereum.

Yeah. Um so I guess one good starting point is is actually the specs. Um, so because we have so many clients, it's just impossible to coordinate with each one of them individually. Um, you know, if we had a a one-hour call with each one of them, we would spend be spending all of our week just on calls. And so instead, our strategy has been to have the best possible specs that we could hope for so that they we don't even need to contact them.

And this has been a success scenario where a bunch of teams, you know, out of nowhere said, "Hey, we've implemented the specs. this is our new client and we had never heard of them because they never even bothered contacting us. Uh you know even clarifying like what some of the specs were. The specs were just uh good enough and um you know I mentioned that the specs need to be AI readable but they also we also want them to be maximally human human readable. So you know go have a look at the specs.

We're right now we're adding a lot of unit tests. Um, Tomar has done a fantastic job um with um kind of uh first-time issues. So, there's a lot of issues that first-time contributors can can provide value um and is is a good starting point once you're familiar with the basics. Uh you know, I would try and find a specific niche that you know you're especially excited about. So, for example, where we have the the peer-to-peer networking layer where because we're dealing with these much bigger postpon signatures that might there's probably a lot of changes that need to happen relative to what we have today with lib P2P and actually there's a new library that was open sourced just a few days ago u called EP P2P uh that Raul from the PC networking team uh has put forward and so uh the idea of of of EFTP is almost the exact opposite of lip P2P.

LI lip P2P is kind of the Swiss army knife kit that can do everything but it kind of it does everything in a mediocre way and then there's EFP P2P which is meant to be kind of tailored and customized for your specific thing. So um you know right now they're working at the at the data layer to try and gossip the blobs as as efficiently as possible but you know the postquantum signatures is a completely different problem um where you have different topologies and you have different message sizes and things like that and so uh one project that could be quite cool is uh kind of implementing uh an ePGP module if you will for for postm signatures. If you're interested in formal verification, you know, there's a lot of of fun work to do there. Um, if you're like interested in hardcore cryptography, you can dig into lean VM. Um, if you're interested in DevOps, actually this this has been a bit of a of a pain point where um, you know, the the dev nets have been quite unstable um, to say the least.

And you know part of the reason was that we just allowed anyone to permissionlessly participate in the in the death nets. And from from now onwards actually we had a call today postquantum inter call from now onwards I think we're going to be much more strict. So you know we're going to want integration we want to want like all of the unit test to be passed. Um we want to make sure that uh your client is stable before it joins the deathnet. One of the amazing things that we have is not just a fully executable spec in Python for the state transition function.

We have the entire client which is executable in Python. So all the networking is is is implemented like the you know database management for close rule everything. So what you can do basically is you can use this this Python client uh for one-on-one interrupt in a pre-defnet if you will locally see if that's stable for let's say a few days and if it is stable then you would go to the to to the the public devet where where you'd be able to test um you know uh with all of the other clients and and right now we have one person Katya who's working on metrics and trying to identify when the things fall over. Basically, she's like one person uh doing the work of of Eve Panda Ops in the context of of of lean consensus and um it would be great if uh if people uh were to to help her.

Oh, thank you very much Justin for mentioning that because I think that's a really great example as Katya was part of the previous EPF cohort. She's been uh she's been part of the study group as well. You could have mentioned met her here as well. So it's a yeah I think it's a great uh great place to uh be coming from uh the fellowship as well. Awesome.

Um yeah um folks I will answer some of these questions in the in the chat but if you have anything else you wanted to ask I'm not sure if you want to go back to the execution or uh just keep asking questions I think we can go for another uh until the till the half pass. Um

yeah happy to talk about the execution layer.

Yeah. Um yeah because we we already talked about it in some of the questions but before you wanted to wanted to give it the overview. So u there is important we missed. Yeah.

Yeah. So in let me start by with the endgame. So the endgame is that um you know we want the signature aggregation and instead of going with lean XMSS which is X the the XMSS signatures uh optimized for lean consensus we're going to go with what we're calling lean sphinx. So sphinx is the stateless uh hashbased signature scheme that N has standardized. Um and it's it's it's it's a very nice scheme.

Actually the I and N in Spinx stands for incredibly nice. Um so it's uh let's see if I can remember. It's a stateless practical hashbased uh incredibly nice uh something signature scheme. Um and basically what we're doing is that we're we're taking the the NIS standardized scheme and we're replacing the hash function sha to to to to pose on um and and here you know as I mentioned previously we have uh we have the aggregation is done on GPUs. So that's why we can afford, you know, aggregation which is 10 times slower because there there's 10 times more more hashes to verify and 10 times more work to do because you're in the the stateless um world, but overall it's it's it's all, you know, very nice and we use this infrastructure.

Now, unfortunately, it's going to take several years. You know, we're aiming for 2029 to deploy this at the execution layer. And so what do we do in the short term? And the the good news here is that even today you can migrate to a whole suite of of postquantum schemes. Uh and this is done in the context of of account abstraction.

So one of the big enablers uh that the uh we're working towards is actually frame transactions. Once we have frame transactions in some sense that's that's all we need. So um you know there's one idea um which is called ephemeral keys which I I really like. It's very simple. The idea of ephemeral keys is that you have um ECDSA pup keys that rotate every time you have a transaction that lands on chain.

So the benefit here is that the the pup key is only ever exposed to a quantum computer for a small amount of time while it's in the meool. And very recently um Google quantum AI had this this this paper which basically looked at um the time it takes to run Shaw's algorithm on even on the fastest uh quantum platforms that that that that we know of today. And even with very aggressive assumptions we're we're looking at several minutes to crack a a a an an ECDSA pup key let's say five minutes. Um whereas you know in the meool the transactions should only stay there for for a few seconds especially in the context of of fossil and uh and you know shorter slots and and and increased gap limits. So if you if you rotate your key fast enough then even though technically speaking ECDSA is not a postquantum scheme when you have ephemeral ECDSA it it it becomes postquantum kind of magically.

Um now this is you know a good you know middle ground for the for the short and medium term but in the long term we have something even better with with lean sphinx and and VM. Uh another kind of short-term solution which is really cool is uh to to use hashbased uh uh signatures. Um, so you can use things. Um, but it turns out that you you can um there's like other other things that that that that you can do. Uh, one of them is that you can optimize Sphinx for blockchains.

So Sphinx is uh is actually a scheme which uh limits the number of signatures that that you can sign safely. uh specifically what NIS has chosen is two to the 64 uh messages, right? Which is some some insane number. It's like 16 billion billion. So no one in blockchains ever sign 16 billion billion messages.

Uh you know, at most you're signing, you know, a thousand or, you know, if you're a power user or like or bot or something, you might you might sign a million, but you you'll never sign, you know, a billion billion messages. And so what you can do is you can retune the parameters of Sphinx plus uh to something that's much more reasonable and you you'll get a a much smaller smaller footprint and and Nico uh from the Kohaku team has really investigated the whole design space and he has this thing called Sphinx minus uh which is kind of a play on words on Sphinx plus where he tries to make the the signals as as efficiently verifiable as possible. And he even has this new scheme called Jarda um which is uh which is even more efficient than than Sphinx minus um and it should be on E research uh fairly soon. And then um there's if you want the option to also use latisbased uh schemes. So you know we have onchain verifiers for Falcon and the lithium.

They will consume a few million gas but the advantage is that they will be N compliant. Um and uh and you know they there will be for example support of of the lithium in uh in in hardware wallets like like the the ledger Ledger Nano S. Um, so if you're, you know, extremely conservative, maybe you're regulated, maybe you're you're part of a security council, whatever, like you might choose to to pay the few million gas, which will, you know, be a few cents. And if you're only making a transaction every six months, then then no big deal. Um, yeah, the the main downside of this solution is that it consumes a lot of of call data, and so it wouldn't scale for to everyone using it.

uh you you would be bottlenecked on call data. Uh so if less than let's say 5% of users do this over the next few years then then then then we're we're fine. Now there was this proposal to have uh pre-ompiles uh to help to assist basically the verification of latis based signatures and you know the specifically the proposal was to have vector math pre-ompile. So you have a vector of field elements and you can do addition and multiplication and that you know with that you can do you know FFTs and things like that and I think this is going to be a useful pre-ompile you know for all sorts of use cases including FAP and verifying snarks um but you know traditionally it was kind of bundled with the postquantum narrative and I don't think it has to be bundled with the postpantum narrative I think it's just a nice to have and even without this pre-ompile so long as we frame transactions, we're going to be in in a really fantastic place in in in in the in the short and and and medium term.

Yeah, thank you Justin. Okay, we have a question. JBN.

Yeah, thank you Maria. Am I audible?

Yes.

Yeah. Okay. Thank you. So yeah, hi Justin. So I have been going through this uh EAP814 on yeah frame transactions for quite a bit and yeah I've been listening to there lot of propaganda over there also but one thing which when I studied through the EAP what I find it difficult there wanted to get your opinion is with the current ECDSA today the meool does exactly one cheap operation before deciding whether to invest on any compute like that is easy But the concept of 8141 we are failing to get this guarantee like we are preventively like potentially like doing expensive frame logic trusting we will get the money after the verify frame actually.

So what do you think on it? Yeah I know there are potential meful ways to uh alleviate it but I just wanted to get your thoughts on that. Yeah. So, account attraction is one of the things that I have not uh looked at pretty much at all. Uh I would recommend asking you Matt or or Felix or or Vitalik or or various other people.

Actually, what you said is is is kind of news to me. I was under the impression that um you know there was this this stateless verification that had a limited amount of of gas that it could consume. basically a gas limit um that was you reasonably small and if you were to pass this this verification uh check then you know you kind of had a guarantee that you would get paid um so yeah what you said is actually news to me and that just shows that uh I'm I'm not an expert in account I can't abstraction sorry

yeah sure sure yeah so yeah what you're saying is correct yeah just but we I think we need to do some compute before that actually so before the verif that's that's fundamental right as you said even in the ECDSA case you have to do some compute namely you have to check uh an ECDSA signature and you actually have to do a little bit more right you have to get the account balance and the nons and you know you need to check the the nons and blah blah blah so you know this is why the minimum gas for transaction is you know 21,000 because there's like 21,000's worth of of work to be on um and you're not you're not guaranteed to get paid. Um and so that that's a little bit of a of a doss vector. Like traditionally the way that you would hedge against the DOSs vector is,

you know, just for example at the at the at the gossip level, if someone sends you garbage transactions, you just disconnect from them.

So you kind of ban the IP address or something. Um and like this kind of soft um you know, civil resistance just works fine in practice. And really what we're talking about, as I understand, with frame transactions is that you go from 21,000 gas to something that's that's larger because you want to express, you know, more complicated things in this pre-verification logic. But, you know, no big deal. It's it it it just it should work in practice.

Got it. Got it. Yeah. In the case of frame transaction, it's like we are deciding what is what we should do in place of easy recover. So technically I can provide a verify function which is predominantly like large and has some like dope there but I guess yeah I can understand what you are coming at also.

So just one more question before jumping into it. So I just wanted to look into this execution layer and on PQ stuff. So is there any place where I can look into it because I see lean spec and yeah all those are like consensus layer mostly.

Yeah absolutely. So um for the execution layer we have a call every two weeks uh it's an ACD breakout call uh which is led by Antonio um and you know anyone can join the they've had something like four calls already so I would encourage you to you know watch the recordings there's not that many um and you know maybe join the next call uh I can put you in touch with with Antonio can share his telegram handle he's very responsive um and he can probably share like some of the open problems that we have. Um I know that Antonio is working you know relatively closely with uh ZK Knox for example. So we gave them a grant and they are like hardware wallet experts. Like one of the the key challenges actually is to make the hardware wallets work.

like we we know how to get postpartum signatures that consume a reasonable amount of gas on the order of 100,000 um you know certainly less than uh than than a million gas and that should be enough for most most most users but the the key challenge is the hardware wallets because uh they're so slow and so hard to program and you know they have limited memory and

for example Falcon signing is uh is I don't think is is is is is been proven to to to to be doable and Sphinx is like doable but it's extremely slow. It takes like a few several minutes to sign a single signature. Um and so if you're a hardware wallet expert then you know we we desperately uh need some clever ideas.

Yeah, I did work on treasure actually. So like yeah it it science bit by bit but so it's like extremely time consuming actually when it comes to hardware. Yeah.

Yeah. Uh if you program trezos then then yeah please do get in touch with Antonio and the ZK Knox team.

Sure. Yeah. Thank you. Thank you Justin. Thank you for Yeah.

Very well. Um I will get back to that later. Uh but Lee has a question.

Okay. Yeah. Thanks a lot. Uh I feel like the hardware issue is not only our issue, right? Considering like there are so many hardware verification uh tools for banks, I assume they should be panic in front of us.

Yeah, that's a good point. Um now the thing is that the the N standards are very very fresh. Actually, the Falcon signature scheme hasn't even been like fully finally standardized. We have a draft. Um, so the only two that are standardized currently is the lithium and uh and Sphinx plus.

Um, and even for Sphinx Plus, there's like a new draft for new parameters that came out just a couple days ago. So, even the standards, you know, potentially will will grow over time. Um I mean I think we should basically expect the next generation of hardware wallets to provide like some amount of support but you know you these these hardware wallets only get refreshed infrequently. Um I mean as I understand um you know it's possible that the the next ledger wallet will will come in 2027 or 2028. I don't know exactly, but you know, because of the release cycles being so long, you know, there's a there's we're in an awkward situation where if you wait till 2029, you'll have the amazing endgame solution with aggregation and everything will be super cheap and super scalable.

Um, but yeah, do we really want to invest a lot of effort, you know, for a 2028 solution? I I don't know. This is this is not, you know, me to make the call. Um my personal guess is that most of the rest of the the world will basically adopt latisbased solutions. That's what NIST encourages and it is very much the probably you know one of the best schemes that you can hope for um if you're if you're verifying signatures on an individual basis.

But for blockchain specifically where we have this batch setting and when we're absolutely paranoid about cryptography and we want our cryptography to live on for, you know, decades and centuries, um, you know, hashbase really is the the the the best solution. And so it's it's possible, you know, we're going to have to come up with uh with our own solutions for for hashbase because the the the hardware the hardware manufacturers won't be incentivized. Well, they'll be primarily incentivized to build latis solutions. One piece of good news is that I believe the next generation of the the ledger will come with ketchup acceleration. So, um you know, we'll be able to to have uh you know, faster Spinx plus signatures for example, at least with Ketch.

Um but yeah, I don't have a good answer to this.

Uh yeah, don't worry. It's a it's already good explanation and I feel like uh splank minus is such a such a good idea because we noticed something uh within similar idea before uh in last cohort of the EPF uh like uh uh MSM for the KG commitment ideally could be pretty slow but uh since in our site In DA setting, we only have like 4,000 points and also we already know all the secrets we are going to use all these like group uh values we are going to use to encode. Actually you can catch a lot of things to accelerate the performance theoretically.

So

Right. Right. Right.

Yeah. So in our setting we can do quite a lot optimization I feel.

I agree. Yes. So there's all sorts of caching optimizations that you can do with with Sphinx. Uh basically you have what's called a hyper tree which is a tree of trees u and you can cache various layers of the tree and um there's like this this blog post that um someone in Bitcoin land wrote um with like 10 different optimizations to spin plus and you like you could see kind of performance incrementally improving with every optimization. So you can go, you know, pretty crazy on optimizations.

And my hope is that we eventually get, you know, signing on hardware wallets, which is on the order of of 1 second, which, you know, is perfectly fine, uh, for for for most settings.

Very well. Um, we have a couple minutes left, folks. If you have one more question, uh, please go ahead. Okay, Andreas had a couple of them, but I guess, uh, you can take the last one. Go for it.

Thank you. Um, so yeah, it's more like a follow-up question about where can we contribute, uh, to link consensus. I think a good part of that question was answered thanks to the GBN question but yeah it's more like uh what are the repositories or what are the efforts being appolate in the terms of developing like the guest program or the CKVM that we are going to use or the pool that we're going to deploy and yeah are going to be like the uh like clients that are going to verify the proofs so yeah where is that code and where we can like actually start contributing to that.

Yeah. Um, so I guess the meta answer that I would give is to talk to Tomar Kaj. So he's the the postquantum team lead, but he's also the the guy who's writing most of the specs and who's shephering um, uh, a lot of that and he also implemented the the Python client. So he's trying to really make this a collaborative effort. So he has these like good first issues that that you can work on that I mentioned.

Um and you know he's very very responsive like you send him a message on telegram and you'll get an answer uh within a few hours uh if not immediately. Um yeah, I mean there's in in some sense there's there's a lot to do but you know in another sense things are are reasonably under control. Um so you know when I started the the beam frame project a year and a half ago I would never have dreamt that we would be at the place where we are today. Uh we're just moving at warp speeds. You know, it's incredible that we have basically specs, we have 10 implementations, we have a defnet, uh, you know, we have this cryptographic library which is ultra efficient.

We've done all the research like we're we're in such an incredible shape. I think now what we need is uh people who have a productionization mindset, right? Like how do we go from from devet to test net and eventually mainet? um you know we we need uh reliability engineers, security engineers, uh DevOps people. I mean when you go back to to the beacon chain when we wrote the beacon specs, we were in a very primitive position where we didn't have any of the productionization team.

So the panda ops team didn't exist. It was specifically set up for uh for for for the beam chain. Same thing for the security team that that's you know a team that was basically spun up uh just a few months before we deployed the the the beacon chain and you know we have the prototyping team and like all of these productionization teams and one of the things that we're seeing right now is that none of like of the three teams that I mentioned literally zero people right now are actively working on lean consensus so zero people from eando ops zero people from steel zero people from prototyping and So there there's a lot of lowhanging fruit and like you can be if you want like the guy who's this, you know, the lean security expert or the the guy who's the lean testing expert or or or DevOps expert. Um, and you know, I mentioned Katya, who's who was who who I I guess is a great story because she she was a she is she she was she was a fellow. Um, and uh I'm, you know, she's a little overwhelmed right now with with being alone having to to work with 10 different clients that are unstable.

And uh I think giving her a knock uh could be uh could be appreciated. Great. That's great to know. Thank you so much. Thank you very much, Justin.

Indeed. Uh I think this is a great place to finish uh the session also because uh that's also where we continue with the study group and with the EPF. uh uh actually uh we will be in coming weeks uh gathering more specific inputs from the all the protocol teams including lean teams uh on where they need help with. So uh uh for the next steps like in uh next month you will see actually some ideas for fellowship projects coming from these teams. Uh we had like green participate before uh the um uh the one in um uh Zen.

Oh my god. Oh, there's so many of them. So, um we will have uh those opportunities also coming for you. You can also check the good first issues on GitHub always and I shared a couple of repos right here. So, that's uh uh that would be the the next steps for you all.

But yeah, thank you so much Justin. Uh let me start with that. Uh it was it was really great to have you here. Uh very insightful. I believe we all learned a lot and it's just very inspiring.

It's just always so motivating to hear you like um this uh technical optimism and just the the the strong vision for the future is it's very exciting to uh to to have to rely on. So thank you so much for for being here today.

Absolutely. And feel free to reach out anytime. I'm Justin Drake all lowercase on Telegram.

Awesome. Oh, that's amazing. Thank you so much, Justin. Very well. Uh and thank you so much everyone who attended.

Uh thank you so much that around 40 people here today. Uh thank you so much for being here for the very last session of the study guru but especially uh for all of those who made it through the two months period of learning and last couple of weeks of these calls to uh always be here and and learn with us. I see the names here that I've been seeing for two months. So it's incredible that you made it. And now at the end uh just yeah one huge thank you.

we will have uh some uh participation badges sort of for you that you can receive to your email that you use to register on the study EPF wiki. Um we will post some information about it later in discord. You can reach out if you have questions. Um also I would like to invite you for uh ETH Prague uh Ethereum conference in Prague in uh three weeks from now. Uh if you can make it there we have a free ticket for you.

Uh so if anyone is interested in eat tickets uh you can also reach out. We will have a post about it on discord. And finally, I would like to invite you uh to apply for the fellowship. So the uh EPF program that we talked about with more opportunities to contribute work directly with the teams uh around all the eat R&D including lean execution, consensus, other research, testing and devops as well. Uh if you are interested in in uh uh continuing your journey as a contributor uh we also have uh we also have the application opening now in a first version for you from the study group.

Um uh Josh if you have the link uh please share that here and please don't really post it. Uh as of now this is like a first release before the official announcement. The deadline is in a couple of weeks. You have plenty of time. This is very early just for you who made it through the study group.

Um uh because it's been it's been uh it's been really great having a community that learns together and uh uh is able to support each other and just progress uh progress so much. Um over the past uh two months we went from like you know what is what is a client what is a consensus layer what is the execution even doing uh to like the wild future of uh lean and and uh everything that's uh uh that's uh waiting for us. And I think the amazing part is that you can contribute to that you can become part of the future. So please check out the fellowship and all the all the repositories opportunities to contribute. And again thank you so much Justin for being here to wrap up the uh uh the the study group.

I think it's been really great and especially inspiring ending to uh to conclude uh this journey. Yeah. Thank you so much everyone.

Thanks guys.

Yeah. Thank you so much. Um, awesome.