EPF6 Office Hours | Justin Drake

Awesome. Welcome everyone. Thank you so much for joining us today. Um got some more people coming in. Awesome.

And uh thank you so much Justin for joining us today. It's of course an honor to have you here. Um I'm glad yeah very glad that you could uh make a make a time to meet the current um fellowship of the the EPF6. So, thank you for being here and yeah,

absolutely. Thank you for having me. Um, and uh I'm actually going to be taking questions on my phone today. Um, I'm in the countryside, so I've I've gone into the low data mode uh for for for Jity, but uh hopefully uh I'll still be able to answer questions with the the mic.

That's all right. We hear you perfectly and it's a lovely nature out there. Uh it's that's really nice. Awesome. So yeah, thank you for taking the time and um uh so uh I don't really need to introduce Justin uh legendary researcher at this point.

Everybody got excited that you are coming um and uh we also uh saw your blog post from a couple of days ago on the link chain. So we pretty much all know what uh you've been up to uh now what what you're working on. Uh but I wanted to ask a bit about your background. I wanted to get a bit of more context about uh what even brought you to Ethereum and what was your journey uh when you were starting to get some um uh get some inspiration for the fellows here who are just starting learning about the uh the journey of these people who are now uh on the top. So yeah, if you could tell us about you uh your uh your story, how what brought you to Ethereum were your your first projects and and so

yeah, absolutely. So actually um the person who got me into uh the space was Dankrat and that was in 2013 before Ethereum even existed. Back then it was pretty much only Bitcoin and he introduced me to Bitcoin I think mid 2013. he sent me some sort of um article. Um but then in towards the end of 2013, there was this uh bubble where the price of Bitcoin went all the way up to $1,000, which back then was a massive deal.

And um during the the Christmas of uh 2013 on I believe it was December 28th, um I created the Bitcoin Meetup group. So that's the meetup.com uh website for for those of you who who know. And basically what I did is I organized events in in in Cambridge to to discuss Bitcoin. And it turns out that um most of the people who came were so-called town people.

So in Cambridge, you know, it's this university town and there kind of the the students and the academics that form, let's say one part of the population, let's say half of it, and the other half is is town people. And it was mostly town people who came because they were interested in speculation. And um um not long after um Danret and I bought an a Bitcoin ATM. So it was this physical machine, this big hunk of metal. Um and the idea was that you would put in British pound notes, scan your Bitcoin address QR code, and the machine would send you uh some Bitcoin.

uh we were not doing it for for profit but uh more to kind of spread the the meme and and and get uh get deeper into the space and at some point I decided to go full-time into Bitcoin. So I quit my job. Dan and I were working for the same company and um spent a whole year doing this Bitcoin fellowship. And during that time, I started a company uh that was building on top of a a protocol called Open Bazar, which uh was a peer-to-peer decentralized marketplace protocol. It's meant to be fully decentralized, fully permissionless.

And um you know, Bitcoin had a little bit of programmability. you could do these two out of three multisigs and that was the basis for the escro contracts. Basically, there was the buyer, the seller and the escro agent that each had one of the three public keys and then if two of them agreed then that was how the the money would flow either as a payment to the to the merchant or as a refund to the buyer if if if the merchant was not delivering the goods for example. In any case, um, at some point, Ethereum came along and I told my fellow colleagues, hey, why don't we look at Ethereum? We're building this complicated marketplace and having programmability is valuable.

And back then, the open bazaar folks were Bitcoin maxis. And they're like, no, no, no. We we need to build everything on top of Bitcoin. And, you know, I was a little frustrated by by that attitude, I guess. And so when uh when my company ran out of money because open bazar went nowhere um I decided to spend a lot of time um learning about Ethereum and I watched this video by Vitalic where he's talking about the the data availability problem.

And so I I decided just to carve out some time in my schedule and I I spent a couple weeks thinking about the data availability problem. And I had some ideas that um seemingly no one else was was having on the internet. And so I I emailed Vitalic my ideas and uh you know he encouraged me to write if research post and and he basically hired me a deaf uh shortly after that.

Awesome. Thank you so much. Uh that's it's uh uh really great to learn uh that I mean you are coming from the OG times from the Bitcoin times and uh I've been when I when I was getting into bit Bitcoin crypto like 2015 16 I remember open bazar being this big thing Amir Taki shilling it like the next generation of uh free marketplaces and uh and uh and yeah it's very very interesting that at the time you uh you've been focused on on um on this and got from the from the customer to more more of a research role. So I'm wondering what um uh what uh before being chain or like what other research you have done. I know you've been working on the consensus the consensus specs.

So if you can tell us about uh your work on the the current beacon chain or the um the consensus related research you've done meanwhile or um how how you started the Ethereum foundation.

Yeah. So I change research topic you know quite quite often every you know 6 to 12 months or so. Um, one of the very first things that I was uh working on was uh sharding. Um, and then um, you know, I went down this path of accumulators which are these like cryptographic objects um, that have certain properties. And the the the the reason why I went down this rabbit hole is kind of uh, you know, I wanted to to cheat the the the the fundamental data availability constraints that that that we had.

But um you know it was it was interesting because I I got to learn a lot of of cryptography and um you know I I ended up um you know exploring BLS signatures that was you know one of the I guess great success from from from from my research. Uh that's part of the the beacon chain. Um, I also spent a lot of time on VDFS that was le less of a success in the sense that it the research didn't make it um into into the the beacon chain. But yeah, at at one point um you know we there was this this crunch right to to move away from from proof of work to proof of stake and all of the researchers or at least most of us were you know contributing towards the the spec writing and and the design and um you know in actually the the term beacon chain um comes from one of my EF if E if research post because the there was this notion of a randomness beacon uh this is kind of a part of the of the cryptographic literature. I was I was kind of obsessed with randomness and like one of the ideas that I had was why don't we have a chain that is kind of the backbone of Ethereum that does one thing only which is randomness right and then once you have that you can build uh you can build everything on top of it um and ultimately like this like very minimalist chain um did didn't come to fruition but we stuck with the name a beacon chain and we made it a little fatter um And so instead of just randomness, it provides all sort of services, right?

It does slashing, deposits, withdrawals, all of all of the the things that you need for for proof of stake. And you know, in the early days there there were very few people at the Ethereum Foundation. I I kind of make this this this this comments that um you know when I came in in 2017 at the foundation I was expecting a a very large and sophisticated team of researchers and devs kind of maintaining this this you know deca billion project and it was you know a ragtack team of like five researchers and so there there was a lot of opportunity basically to be proactive and pick this lowhanging fruit um and you So that involved, you know,

helping with the architecture of the design and the naming and and like the nitty-gritty specking as well. So, um, you know, one one of the one of the the the great outcomes, I guess, of the of the beacon chain is that we have an executable spec. And, uh, the way this came about is that Vitalik uh, was and other people were writing the these little snippets of of pseudo code. um that were basically meant to describe the chain and then at one point I was like hey isn't there now an opportunity to write the whole thing in Python end to end and make it executable and um and you know the type was kind of nerd sniped and in a week or so he he he wrote the whole thing at least as a first draft um and then I spent a lot of time kind of going through it line by line and and and and polishing it and simplifying it and finding bugs and and and all of these things. And um you know, I I really like the the the spec writing process and the idea of getting to the essence of things and having them as simple as possible, as as as beautiful as possible.

And one of the things that I I remember telling Vitalic back then is that there's this huristic, right, which is that um if your spec is ugly, it's probably not done, right? It's probably not fully baked. there's like opportunities to um to improve it. Um and and I think this intuition still holds, right? Where until you've got something that you're really pleased with aesthetically, like your your taste, your intuition says yes, this is good, then there's there's there's still juice juice to squeeze.

And you know, with the migration away from proof of proof of work, we had, you know, time pressure for several reasons. One is that you know um we were issuing a lot of ETH we were also burning a lot of electricity worldwide on the order of.3% or something like that and also you know we had made these um you know soft commitments to the to the community around when we would actually shipped proof of stake and we were kind of running late and I I take blame for this you know I remember when I I joined the foundation a few years uh on you know I was making you know predictions you know we'll ship been 2021 or whatever 2022 and um or I I forget the exact dates, but a lot of my predictions ended up being way way too optimistic. And so um you know, we we did a best effort with the with the the beacon chain. I think it's extremely solid and it can definitely support Ethereum growing to you know, trillions of dollars.

Call it 1, two, three, four, five trillion. But I think if we have the ambition and scale to grow Ethereum to a you know 20 trillion hundred trillion dollar network you know both the the ea the asset itself but also all of the internet of value that would come into it and you know potentially hundreds of trillions of dollars then I think we need to to go back to the drawing board and and fundamentally rethink things and it's not just about um you know things being not fully baked but it is also about fundamental new forces that that come into play. you know there's things things like like uh quantum computers that means that we just have to rethink the BLS signatures for example that I mentioned u but also you know we have this massively powerful tool snarks which I think as being you know just as powerful as hashes and signatures right we we've gone so far in the in in in in the world of blockchains with just hashes and signatures and now we have this third primitive and and and I think there's just so much juice to squeeze from from snocks that it's worthwhile having a snark first approach to design, right? And and and seeing how far we can get with that.

Well, thank you so much, Justin. Uh you get uh you went all the way to the future there. I wanted to get there, but um thanks for sharing all of that. It's uh honestly like I'm very I'm surprised right now like uh it's it's um it really got me the information that the beacon chain comes from like a beacon randomness beacon. I I honestly didn't know about that.

That's it's it's a really nice piece of Ethereum history. So thank you so much for that. Um and um yeah um so this is supposed to be AMA. I just wanted to take a couple of minutes for the intro. Um I uh I can still more questions for myself and I but I want to open this to the audience.

We have 30 people here already. So if you have questions please feel free to raise your hand and ask feel free to write in the chat um and if there are no questions I will take one more for myself. But um we already started dipping into the beam I'm sorry lean chain now uh and the uh the future of Ethereum and we have a bunch of fellows uh working uh contributing to uh beam clients and benchmarking and uh the efforts. So I hope they will have some interesting questions. Uh Lee lost uh I think Lee has a question if I see first one here.

Yeah.

Yeah. Hi thanks. Uh hi Justin. Actually we saw each other before um uh I'm also working on uh data availability assembly and uh I'm wondering from your point of view what's the biggest challenge or the issue of the pure das or the fas now because I mean we already have the foundation paper uh and also other like zoda fa all these designs but uh it looks like uh from the network side is still some like challenges and also like yesterday or day before uh at SBC there also like the work from Dumbo about the repairability and it looks like still a lot of things need to be done but I'm wondering from your side what's what do you think would be the major challenge there

right great question so one of the disclaimers I want to put forward is I'm not an expert in data related sampling. Um, you know, I' I try to be as broad as I can and I touch many many different topics in my research including, you know, base rollups, native rollups,

everything that has to do with the consensus layer excluding the the data sampling and now I'm kind of also moving towards the execution layer with with full stockification. uh and I'm also very much interested in in ME but just from a sanity standpoint I've decided to scope out of my research remitt the the data valy sampling having said that um even though I'm not interested in the the kind of short and medium term of of of podas I do think that um there is an opportunity to rethink database sampling you know over a longer term time frame let's say 5 is and there's kind of several reasons for that. Um, one is that KZG right now is not quantum secure. So just like we have to change BLS, we also have to change uh KC. So that's a good forcing function to to to change things, but it's it's also an opportunity, right?

Because we're in some sense it it is the cryptographic foundation of blobs. And so if we change that we we have we have an opportunity to rethink everything. Now one one of the things that has been a pain point for um L2 developers is like rollups that are consuming the blobs is that the blobs have a fixed size right 128 uh kilobyt and what that means is that um you have to worry about uh blob packing and you know like blob like efficient blob constru um usage. So if you if you have for example only 50 kilobytes of data then you you know you're going to wait a little bit in order to have a full blob and and that that introduces latency. Um and you know if you the the best approach I guess that that we have with the current blogs is this idea called blob sharing where you have multiple L2s that share um the the data settlement so that they can make best use of blob.

So that introduces it its its own um can of of worms and and complications. And so in my opinion the best approach is to go back to um something like call data where if you want to consume 10 bytes of call data you can do so. If you want to consume you know 42,000 bytes of call data you can also do that. So it's basically flexible sizing and I think there's an opportunity in in blobs 2.0 you know uh to to offer that as as uh as as for for for for the devs.

Now the other thing is that um Vitalik for a very long time now for many years has been wanting to extend data availability sampling beyond the blobs. So he wants to do database sampling on everything. So that includes the the L1 block data, the L1 headers and even the beacon chain. Let's do data sampling on that. Right?

Because like right now um like if you want to check the availability of the beacon chain, you actually have to download the blocks. But wouldn't it be nice if we could do database sampling on the beacon chain itself? Um and so there's this idea that um you know I've been calling in under various things. So for example uh the meme is like uh a mega blob, right? So we we just put all of the data on Ethereum into one mega blog blob and and we do datability sampling on that.

And if from the point of view of the the L2 that's consuming the blobs, it's it's this is a a detail that's abracted away. They're not they're not exposed. Another thing about blobs is that right now the the format the native format for posting data is uh the the the KZG native prime fields which are are not um aligned with the uh with with uh you know by you know bite bits and and and byes right it's it's it's it's this weird prime that you have to deal with. And also not only that but if you're if you're dealing with stocks for example you have to or or some other um committance scheme in the case of zkaps you need to prove the equivalence between the the format you have in blobs and the format that you use for your proof system and that increases and introduces even more complications. So I'm hoping that we can just have a binary format which is flexible in size um and that's going to be so much more um efficient.

Now one of the things that you mentioned is uh Freda or Frieda. Um and this is uh this is kind of very in an interesting idea right where you can potentially combine efficiencies of snarkifying the L1 with database sampling. And um that's something that I guess we would consider in the context of uh an enshrined uh ZKVM for the L1. But right now it's too early to think about enshrined ZKVMs. The short-term um stepping stone towards force notification of the L1 is to rely on client ZKVM diversity just like we have diversity at the CL and the E.

And that's how we would deal with with security. um in order to get an enshrined ZKVM we need to have full end to end verification and if we're going to pick one it needs to be really really good and fried is is definitely a very interesting research idea.

Yeah, I agree. I also think like especially for your first uh like first question about post quantum fa looks pretty promising and also for like uh uh for the native field thing like k's field thing fa based on harsh so it's it gives a lot of opportunities to optimize that part although we can use other commitment schemes but definitely harsh is something like simple enough especially for the implementation part. Uh I'm also I'm actually visiting Mark and Matias recently. So yeah, we also discuss a lot of that. Yeah, thanks a lot.

Sure. I mean one small note is that in my opinion um FRA sorry Fry um has reached its peak and it's going to be declining from this point onwards and the reason is that um as a you know IOP um as a proximity test or as a as a polar commitment scheme um it's it's now outdated. So there's better versions of uh PCS's for example were um that have just better properties all around. They have smaller proof sizes um they have um uh you know faster approvers and if you want to do recursion uh they they're much more friendly to to to recursion as well. So that is something that the foundation is actually investing quite a bit of resources in um because we uh in the context of postquantum signatures we have this uh cryptographic ZKVM to do the the recursion and and and here we're we're definitely leveraging were and um I think once the big libraries like clon 3 and whatnot support were um then um we will see a gradual transition away from fry.

Yeah. I also I also like war. I also like war a lot. Uh but uh I mean it's very new research. So I'm wondering like uh I mean it takes time to really verify the uh sunlight security and everything there.

So but uh yeah and uh I think fence did a really nice job. So I'm also looking forward to that. Yeah. Thanks a lot.

Absolutely.

Thank you so much guys. Um yeah interesting conversation and we have another question from

hi this is Tim and Mario so I had a question specific to beta signatures since they would be entirely removed from lean consensus and we'll be using postquantum signatures so uh has any thought been put into how exactly the random mechanism would change since uh we'll still be using signature aggregation Yeah.

So would the internal logic of randomness still remain the same?

Yeah.

Okay. Great question. So you are right that today we use BLS signatures for randomness but we actually don't use the aggregation part. So there's another network called the internet computer also known as defininity uh that was indeed using uh basically threshold BLS signatures in order to do randomness. We don't we don't do that at all.

we're just using BLS uh as a PRF pseudo random function and it turns out that you know there's other other such things you know including just a hash function right so you right now what we're doing is that we we take the uh I believe it's the epoch number and then we sign it with with BLS and that's going to be and then we hash the output of that but we can just remove the signing part and just do just do hashing and Um, and it it will work just the same. You can you can think of the what we're doing right now as essentially being commit reveal. So you've committed to all of these um random strings at every epoch with your BLS pup key and then you reveal your randomness by by sharing the the the signature. Um, and you know, there's there's like some reasons why we did that, like some some technical reasons, but it turns out that it's it's it's optional. Um, and we can uh just have a normal uh you know, postquantum signature.

Um, sorry. We can just have a like some something else like like a hash chain or or or or or even like a a normal uh signature uh scheme or or or or what we can also have is basically um something where uh every time so every time that you reveal a pre-image you you also submit the uh the commitment to to the next pre-image. So you you submit an image. Um so long story short is that it's not a problem. We can totally do it even in a a a postquantum world and it doesn't have to use fancy technology.

You can just use commitments and hashes.

Oh.

Okay. Thank you. If you have more questions, please raise your hand. But before we get to those, we have some questions in the uh in the issue uh from people who couldn't make it, but I wanted to ask you a question. Um and uh the first one was uh the I wanted to get back to the one that you all basically already answered in the in the chat.

Um uh it was about Stark and Snarks and uh you say that Starks are snarks and we like our snarks transparent at L1 which makes sense. But I want to ask you to elaborate a bit about this. The question was like why snarks over starks. So uh uh maybe to broaden the question up a bit like what uh what is the design space here like what kind of uh uh argument protocols or what proof uh systems uh have been considered what are the tradeoffs and um uh and yeah uh if you can give us more context on the on the starks and stark discussion and transparency here. Yeah, absolutely.

So the broadest term that is kind of relevant in the in the industry is a snark, right? Which stands for succinct non-interactive argument of of knowledge. And uh within this very broad bucket, there are subasses of of of snarks. Uh one of which is the transparent snarks, which are snarks that don't have a a trusted setup. And if you are transparent that is definitely a a a positive.

There's also another bucket which is known as postquantum uh snarks. So uh those are um those obviously that that are secure against quantum computers. Now you know there's this very common misconception right for example that um stocks means postquantum and that's actually not at all the case. There's nothing in the definition of a stock that means that it's postquantum. Actually, there are there are um uh stocks that are not postquantum.

U so you know there's uh there's there's there's Halo 2, there's uh there's bulletproofs, there's there's there's there's Nether, you know, you can build transparent snarks uh w without them being being posted insecure. Um and um you know in the context of the L1 we we want to be simultaneously transparent and postquantum. Um and the the best way to do that is to actually invoke a third class of of of of snarks which is uh the hashbased snarks. And the hashbased ones are um you know in the intersection of the two previous buckets which are the transparent SNS and the postquantum secure ones. And you know you can call them HB snarks if you want hashbased SNS um and um and and and those are are are really really awesome and um they're the ones that we're we're looking into.

Uh now traditionally you know these these HB snarks were built on top of fry but then you know as I mentioned there's like better technology now such as such as wear and uh that's what we're we're looking into.

Yeah, thank you so much uh for explaining that. Awesome. Yeah, that that clears it up very well. And um please raise your hand for more questions. We still get a bunch of time so you use the opportunity to ask and chat with Justin otherwise I have one more question from uh the issue but yeah we have someone in person that's great ammon uh we talk about like diversity of zkms what proving in real time and there are multiple zkms working on real time proving but uh the zk most of the zkms rely rely on grid soluble CS and protocol like FI.

If not, most I think ZK stacks rely on these and so is there any efforts on moving away to bombs?

I mean the the sound your connection is not super. Could you repeat the last few words? Moving away from retail element to what?

Proven bounds. Uh

proven bounds. Ah okay. I think what you're referring to is the proximity gaps conjecture. So basically uh when you work with with Reed Solomon um you can uh basically analyze your soundness in various ways. You can either have, as you said, the the proven uh soundness bounds that will lead to slightly larger proofs than if you were to pick um basically your your your soundness parameters um based on the the worst case attacks that are known.

So in some parts of cryptography, for example, in with hash functions and with things like like pairings, the way that we determine the bits of security is by basically looking at the the the best known attack and then defending against that. But in the in the context of of um hashbased SNS which are which have these information theoretic um foundations not cryptographic but actually information theoretic which is much stronger. Um you can you can have provable results. Uh and so that is a a lower bound not an upper bound on the on the number of bits of security. And the the great thing about these these these provable results is that you know they they they will they will stand the test of time like they they will they will stand for for the rest of of of uh of of the the lifetime of of the universe and so it's very robust foundations but the the the downside is that they lead to bigger proofs.

So the the gap between the provable results and like the most aggressive assumptions about 2x and so basically your proof sizes are about twice as long if you rely on on provable stuff. Um now the the the great thing is that um over time over the last five years or so we've made quite a bit of progress um proving the different conjectures. So there's it turns out there's a whole zoo of conjectures. So there's like um you can think of it as a as a 2x two sorry um a two-dimensional grid where on the one hand you have the the flavor of of the of the the conjecture which is for example there's um correlated agreement there's something stronger called mutually correlated agreement and then um there's there's uh something known as the the Johnson bound and uh you know the unique decoding radius and um you know app to capacity. In any case, all of this is just technical detail, but there's there's multiple open conjectures that have been proven over time.

And actually, in the last few days, um, one of the one of the conjectures was was was proven. And now now we're basically down to um essentially like one one open conjecture uh that that still needs to be to be proven. And that's that's kind of the final boss and it's quite a hard one. Um, now in the context of the L1, ideally we wouldn't make use of this conjecture. We' just rely solely on on on the on the provable soundness, but um I think for the ZKVMs that are not being um enshrined, it's actually perfectly fine to assume the conjecture.

And why is that? Well, one of the reasons is that if you're aiming for 128 bits of security um with the conjecture and the conjecture turns out to be false, then you you're going to degrade your security, but you're still going to have something very high. Let's say for example, 100 bits. So, you degrade from 128 bits to 100 bits. In practice, a 100 bits is way more than enough, especially in the context of of um of uh snarkifying the L1.

And the reason is that the the the way that the attesters would operate is that for every single slot, they would download the proofs and verify them at at that moment in time. And so what an attacker would need to do in order to break the system is within the span of 12 seconds generate a bad proof. But there's no way, you know, 12 seconds is a very short amount of time. And so if you look at all of the energy that is produced, all the power that's produced in the world, you know, it's something like um 5 terowatt, like 5 terowatt, 5,000 gawatt is is is not enough to to to um to break a proof in 12 seconds with 100 bits of of of provable security. So um I'm not at all worried is the the the the long the TRDR.

I'm much more worried about much more mundane uh bugs, right, where you you have some sort of under constrained circuit, for example, or or you you're not doing the fiat jam properly. You know, there's been quite a few of these these bugs in in in production. Um and here, you know, there's there's various things that we can do, follow best practices, there's audits, but also more and more we're starting to enter the realm of formal verification. It turns out that there's there's something that gives you 80% of the benefits of formal verification for only 20% of the cost. And that's basically a solution that was pioneered by a company called Veradise.

And what Veradise is doing is that they're specifically t tackling under constrained circuits. So they you give them a circuit and you know they'll they'll break it down into small modules and then for each module they'll prove it's not under constrained and then they'll they'll patch everything together all the pieces of the puzzle and prove that the whole circuit is also not under constrained and there was this study that was done they they looked at a 100 different snark bugs and something like 97 or something out of these 100 were under constrained bugs and um what we're seeing is that Veradise is being hired by all of the top ZKVMs. So, for example, Risk Zero and SP1 and uh I possibly OpenVM and others. Um and and what we're seeing is that every week or so, like there was just an announcement two days ago where there's a disclosure saying, "Hey, this tool from Veradise found an under constraint bug and and and we're reporting it. Everyone, please update your systems."

And so I think once we reach that point where uh the very nice tool has been used over the whole codebase the full circuits um you know I'll be able to to sleep well at night and and and and even even if the ZKVMs are used to to snarkify the R1 mainet.

Thank you so much that was for the details answer that was super helpful. Awesome. Thank you so much, Justin. Really great answer there. Very well.

Yeah. Um, Vladin, uh, do you have a question or do you want to ask the one from the issue?

Yeah, I want to ask the one from the issue. I I I thought I couldn't make it, but yeah, here I am. Happy to be here. Thank you, Justin, for having us. Um, so I'm working on a proof of concept for a delegation model.

Um and I have a couple of questions regarding uh regarding this. First of all would be uh how do you think beam chain will uh integrate staking frameworks? So I don't know rainbow staking or if there's any other ideas and the second question would be uh I'm curious to see what are your thoughts on enshrining the delegation itself in the protocol. Yeah, absolutely. Great, great question.

So, right now in the beacon chain, there's one role which is called the validator and they're responsible for everything, right? They're simultaneously an attesttor, a block proposer and uh an includer in the context of censorship resistance uh for L1 transactions. Um and also you know they participate in the sync committee and uh you know possibly uh some other miscellaneous things and you know one of the insights of the last five years of of research is that if we have more specialized roles we can achieve our goals you know better and faster. Um and one prime example of this is what is known as APS at tester proposer separation. Right?

If we take these two roles at testing and proposing and we separate them, then we actually get much better outcomes. And the reason is that in order to be a very good proposer, you have to be fairly sophisticated, right? You have to like today the way it works is you have to pick a relay and you have to play timing games. And when you receive me, it's going to be very spiky. So it's a bit like a lottery, right?

You only select it as a proposal once every six months or so. And when you do win, it's it could you could be winning, you know, a 100 ETH block or thousand ETH block or you could be winning a 0, you know, 0001 E block. And so, you know, this leads to the desire to have smoothing pools, for example, and and that is is all complexity that that we that we don't want. And so with APS, you know, we have two separate roles, our testers and proposers. And the testers can be maximally unsophisticated.

they could be running on a, you know, Raspberry Pi Pico, which is a eight dollar piece of hardware, and that would be sufficient to to do the job. Um, and the the proposal role, you know, could be basically embraced by u more sophisticated builders, for example, like the ones that we see in the context of me boost today like like BeaverBuild and and and and Titan. Um but yeah if we have sophisticated entities responsible for proposing then we also need this this other role which we call the includers and the includers are responsible for censorship resistance and you know the the proposal that we have right now is called fossil and um the it turns out that there's there's two different variants of fossil. There's one where um the attesters um you know are automatically enrolled for example as includers but then there's also a version of fossil where anyone in the world that holds ETH can just deposit E and not be in a tester but still be be an includer. Um and then uh in addition to all of this there's what you mentioned which is delegation right where you want to be a staker in the sense that you put forward stake but you're not interested in actually performing the duties yourself right you don't want to be an tester you don't want to be a proposer and you don't want to be an includer so basically the the way that I'm thinking about it is that in the context of the beam chain that has been renamed to lean consensus the first the the the the the first class kind of role the most basic one is actually a staker.

So we in some sense we get rid of the notion of validator and we have staker as the the the prime concept and then the staker can customize exactly what it wants to do. So uh it can opt into a testing or not opt into a setting. It can opt into proposing or not. it can opt into including or not including um and and and and that's basically how I I think about it. So the minimum amount of ETH that you need to become a staker is one.

So you deposited one E and once you have that you can opt in to the various uh roles including you know attesting uh proposing and and including now the one caveat that I want to highlight here is for attesters specifically. So we we want to have low latency finality. What does that mean? Is that we want to have every consensus every atttor um you know participate uh towards finality in a very short amount of time. At minimum they need to sign one message.

And so we need to be able to aggregate messages from all of the testers within a small period of time. And the bottleneck here is is is this dis this aggregation. So what that means in practice is that we're going to have a limited number of spots for the testers. That's the proposal that we have right now. Um you know, think something like 16,000 or 32,000.

And this number can grow over time. And I'm hoping that it grows to on the order of of 1 million um at testers. But yeah, like at the launch at the genesis of of the the lean consensus chain, my expectation is that we're going to have, you know, possibly uh 32,000 or something uh at testers. And that's going to mean that there's going to be a minimum deposit which is going to be greater than one E. And I'm I'm hoping that it's going to be less than 32 E, but we'll have to see.

And the reason why I'm I'm hoping it can be less than 32 E is because right now on the beacon chain we only have 8,000 operators. So these are like distinct entities with a unique IP address that are actively participating in in in in staking. And so if we have perfect consolidation um then we'll have enough space for for everyone to who wants to participate with at with uh with with with 32 E. Uh but actually the the minimum deposit will be probably quite a bit lower if we do have this this best case consolidation and and it might it might be the case that everyone can participate right with one each and the reason being that we might only have demand for 32,000 uh staking operators out there. But the the big unknown basically is how much consolidation we're going to see.

So we could imagine some sort of adver some large staker for example Coinbase just to to pick on them because they're very large. they could decide to not consolidate and and they would basically consume all of the or many of the slots and and that would increase the the minimum deposit in order to become an tester. But uh the good news is that I my personal conviction is that almost every uh staker today is highly aligned with the the health of the of the network including Coinbase and so they would have you know very strong consolidation um leaving lots of slots for for our testers. But my long-term plan, you know, um, in in in when we assume that there's these these adversarial entities that don't consolidate, uh, would be to basically just increase the number of of slots for our testers. And so the way that we would achieve that is um with the the doubling of bandwidth.

So the the number one constraint with aggregating postquantum signatures is bandwidth. And the reason is that these these signatures are actually quite big. they're on the order of of a few kilobytes, specifically three kilobytes is is the post quantum signatures that we're looking at right now. And so um every time uh bandwidth doubles, we can we can grow the number of attesters. And actually we can grow it by a factor of four.

And the reason why we have this quadratic scaling is because we have this two-level two-level aggregation where you know we um we split all of the attesters into subnets uh each uh each of size roughly square root of the total number of testers and then we aggregate within the subnets and then we pass the aggregated signatures to an intermediate aggregation subnet that will aggregate the aggregates if you will and then you end up of one one final um super aggregate. And um because of this these two levels of aggregation, you have this this quadratic effect. And so um if we if we start for example with um 16,000 signatures in order to get to a million, it's it's it's it's only like three doublings. Um and so um it's it's something that's that's totally plausible on on on the time frame of of six years roughly because um Neielson's law says that roughly speaking every two years bandwidth capacity doubles and so over over six years you'd get the three doublings that you need and because of the quadratic effect we can get to a million testers.

Yeah, this this sounds really interesting. Uh uh just one clarification for me uh on these testers. You said they they can assume different roles. Uh they can uh assume one or many roles, right? So antor

just the takers. Yeah. They could potentially do many roles at the same time or do they have to

Okay. there would be function in a in a light client future, right?

Yeah, exactly. So, you can imagine some sort of um when you register there's some sort of a bit string uh where you know you turn on and off the attest knob, you turn on and off the includ uh and and and same thing for all of the other knobs. Uh and there might be like four of them for example. Um and some of the rules are not going to be like client friendly. So maybe the best example here is uh proposing, right?

Proposing is meant to be like a sophisticated thing where you want to be running a full node that that that that has all all of the state so that you can build the best blocks possible. Um but if you're just in a tester, that is like the maximally simple thing. Actually, the maximally simple thing is just delegating without even a testing. But the next level after that is a testing. And then the next level after that is including.

So it turns out that in order to build inclusion lists, you only need a very very small subset of the the Ethereum state. What you need is all of the the pup keys, the nonses, and the e balancers, but you don't need all of the rest of the state. Um, and so, you know, there was some it's called like partial statelessness. Uh and there was some research on on on how big the amount of state you need and it's it's it's on the order of of 10 gigabytes uh which is quite a bit of smaller than the hundreds of gigabytes that you'd need otherwise. Um but the the good news is that there's actually even more clever ways to make it to make it uh even more like line friendly where you don't even have to store uh that data.

But uh yeah, it's it's just um we'll we'll we'll see how the statelessness space evolves. My hope is that we're going to see a golden age of statelessness because with with snarkification of the chains, we'll be able to have stateless clients in in browsers and wallets in in in phones, something that we don't really have today, right? If you if you're using MetaMask, you're intermediated uh by Infura and Consensus and and and MetaMask itself and um and that they're giving you data that you and you're basically blindly trusting them and um I'm hoping that we're going to see much more tooling and uh and infrastructure around statelessness so that yeah, even the includers can be uh extremely like client friendly.

Yeah, I agree. stateless is definitely the way to go even though it's not an easy solution to to to come to. Yeah, thank you for for your answers.

So the nice thing about the partial statelessness is that it is a very easy solution. You're literally just taking a subset of this data and calling it today. And you know it is 10 GB so it's not friendly necessarily to a phone for example, but if you have a a laptop lying around it's perfectly fine. Yeah, that's Thank you.

Okay, thank you so much guys. Um, we are we have couple of minutes left only and uh before you wrap up I wanted to take the opportunity to take uh ask one more question uh here from Justin. Um I wanted to um I wanted to ask for some advice uh that you would give to people who are starting in Ethereum today as developers or researchers or just starting to contribute. Um maybe something that you wish you knew uh years ago when you were starting, something that you had to learn the hard way. Um yeah.

Uh but do you have some some advice to give before we wrap up here?

Yeah, I that is that is a hard question. Um, one of the things that comes to mind here is that the FM foundation has gone through this pretty massive reorg and now there's um a lot of infrastructure out there to uh to help out people entering the ecosystem and we actually now have a whole echoev uh cluster of people you know on the order of uh I don't know exactly maybe 50 or 60 and and and and we're hiring a lot and you know within these teams teams, you know, we have uh, for example, a founder success team. So, if you're a new entrepreneur, you want to build on top of Ethereum, there's like a team that that that that can help you. And that's something that didn't exist even just a couple months ago. Um the other thing that I'll say is that um you know the you need to be very proactive and and and you need you need to be able to be very independent and in some sense you you know probably everyone here in this room has this these traits right because you're uh you know Ethereum is extremely technical and so there's a a large amount of self- selection there and you know it also really helps if you if you believe in the mission, right?

In the ideology and the philosophy of Ethereum. Um, you know, you're not here to make a a quick buck. Um, and um, yeah, the other thing that I'll say is just just just just reach out. Um, you know, that's how I got hired, right? I just reach I just wrote an email to Vitalic and he responded and um, and you know, I I definitely encouraged that a lot.

And one of the things that's not very well known is that uh I'm probably the number one hirer at the film foundation. So I I've must have hired something like like 25 people uh within the the technical part of the foundation which is the the protocol cluster. Um and uh usually the way I do it is basically I I encourage people to to reach out. So uh uh you know for for for Ethereum 2.0 I you know I had this email address e2.

org or and then when I was firing for security people security.org we're going to I I'll drop these email addresses in tweets or at the end of a podcast or something and uh I like doing that especially towards the end of so if if I have a very long for example bankless episode that lasts two hours I'll drop it at the very end and so the people who who reach out are those who went through two hours of of of podcast and you know you're that's already quite a good signal um and I mean another thing that I'll say is that um G foundation is hiring and now we actually have a site with like a bunch of open positions. Um, and yeah, I would just I, you know, encourage you to just just do things, you know, like, um, grab well or find what you're passionate about and just just start tripping at it and and you find the open- source repos that that you enjoy and um, you know, fix some issues, submit some pull requests, and um, you know, it doesn't take much to figure out if there's good chemistry with the rest of the team. Um, you know, a couple PRs in and and and and there should be good intuition and you know, that's for example how a lot of the the the GE team was hired. It's just external contributors that that submitted very high quality PRs and and that's how they got noticed and and that's certainly how I've hired like many people at the Foundation as well.

um you know for example you know Mike Nudder um you know he made some contributions to the ultrasound relay that was that I was working on and I was very impressed and and eventually he joined the foundation. Um you know same thing with proto lambda for example um you know I had this bounty 10 eve bounty which today is a large amount of money but back then it was a little bit less um a 10 bounty to write the whole uh beacon chain spec in less than a thousand lines of go code and and he whipped it out in three days or something uh and I was just so impressed that you know he joined the foundation just just do things um build your reputation be in it for the right reasons and and things will just naturally And you know in our space the number one bottleneck is talent and so you'll have people clamoring for your skills uh if you can if you can build a good reputation and we're potentially at the very beginning of a massive bull run. And uh usually what happens is that during these these these manic bull runs um there's just a a huge amount of interest and inflow of of of entrepreneurs and investors and all of these things. and and you know this is a a prime position to be to be a developer or or researcher whatever it is people will want your your talent.

Awesome. Thank you so much Justin. That's very inspiring very motivational uh way to to wrap it up here. Thank you so much Justin. That was awesome.

Yeah. Yeah. You can just do things. Um it's uh uh that's very nicely said like Piper who started this program always said like the door is wide open. you can just come and contribute.

So that's what we're trying to to do here. Um I really I really appreciate that and uh also like the foundation being more open now like that's uh that's very great. Um awesome. Yeah, we are a couple of minutes after the hour. So um we are going to to finish the call here but uh thanks again everyone for joining and uh Justin uh yeah it was great.

Uh I I felt it flew by so fast like we had a couple of questions and you just uh speak very broadly. Um but yeah, I believe we learned a lot. We um we get we get inspired for sure. Yeah.

How do you feel everyone?

Yeah,

absolutely. Thanks for having me, guys. And have a great day.

Thanks again, Justin. Thanks for your time. Awesome. Cheers. Yeah.

Enjoy the nature. Bye-bye.

Bye.