EPF7 Office Hours - Matt & Nico

Transcript

recording is on. >> Okay, hope this works and yeah, let me welcome everyone once again. Thank you so much for joining again for a very special edition of EPF office hours. We got two guests today. Uh we got Matt and Niko from Loadar. So, thank you so much for joining us. Uh it's an honor to have both of you here. Um uh yeah, very awesome to have like two core devs working on consensus clan and loadar uh uh two experienced devs. I hope uh you guys can get some inspiration from them.

Uh but before we get to the AMA and questions from uh from the fellows, from the audience, I just want them to get to know you a bit. Uh so uh please just tell me about yourself. I I uh I wonder like um uh what you did before Kiru maybe. what's your background and what led you to work on the core development? How did you how did you end up uh in Ethereum? Uh yeah, whoever wants to start uh feel free. >> So I guess I can quickly start. So uh so Ethereum I was involved pretty early I guess around 2017.

Um, I started as like a smart contract developer and like did security audits there. Um, yeah, but really what got me interested first was Bitcoin. I guess before that I was just interested in having like soenity uh over your own money and just being ungovernable by by or like having a system that has no third party that can prevent anything you're doing. Um so that got me started. Uh so I worked on Ethereum a bit mostly on the app layer. Uh then I did some web two stuff which was bit related to blockchain and uh yeah honestly like just boring uh

consulting work. Uh and then uh I guess in 2023 I uh joined the loadar team. Um since then been working on the protocol. Um yeah, mostly working on on loadar and also uh working on the spec side of things. >> Nice. Thank you. >> Yeah, Matt, go ahead. Feel free. >> Hello. Uh my name is Matt. Uh I uh I've been around crypto space for a long time. Uh my first career though was real estate development and I was taking a short sbatical well not so short and I

found Bitcoin sitting on a beach and just kind of uh wanted to know how it worked. Uh so I taught myself to program in order to be able to uh to just not have to trust anybody's bull bad ideas or or lies. I wanted to read the code myself and uh and I honestly thought I would end up working in Bitcoin protocol uh development and uh I was at Devcon. I was working for an NFT company at the time just one of I had a few tech jobs before I ended up uh doing this but uh I was at Devcon and I happened to be sitting next to Barnabas. if you know Barnabas is one of the the lead uh in e

pandops and uh we just started talking and he's like ah I have somebody you need to meet and so he talked brought me over to the loadar team and uh the rest is history um so it's just an honor and a privilege uh actually I'd like to say it's humbling and invigorating to work around some of the brightest and most talented people uh not just developers But uh just brilliant, kind, hard-working, uh just amazingly uh impressive people is like the the the core development community is is mindbendingly mindbendingly good at what they do.

>> Yeah, thank you so much, guys. Oh, that's awesome. I mean, I didn't realize we have two such an OG's here uh going way back and like I um yeah, I'm excited to hear that. I also like started with Bitcoin basically and uh uh it's uh um it's it's great to have the same class of people here uh now uh thank you so much for the nice words like I I very much agree like u working in the core development is very very humbling as well just like seeing so many so many great people around uh it's very inspiring so I'm wondering like uh what do you actually work on these days what sort of uh what is your role in the team what are your current uh prior priority ities maybe. What are you excited about

upcoming in the protocol? Um, yeah, tell us about your work. >> My primary job is making sure Nico's happy. And and if you guys remember the bracelets, it was WWJD, what would Jesus do? Instead, it's our team is WWD, what would Nico do? He's the standard for quality in all things. Um um just a superstar by the way because I I wish I had your talent. Um and uh I am engineering manager for the lowest team.

I am a protocol developer. I do uh do do uh code. Um and but uh yeah I I forgot what the rest of the rest of the question was but yeah I'm I'm a programmer and uh love being part of everything. Yeah, maybe what parts of the client or what coming upcoming features you are excited about uh upcoming hard forks maybe what uh yeah what are you looking forward to or yeah >> awesome uh yeah so I'm working on uh the uh partial messages so doing some networking stuff right now also part of the uh P2P working group and going to be focused on the the gossip sub replacement so that's going to be

something that's going to be upcoming over the next year or so uh very interested to see postquantum come to Ethereum. I think anything that gets in the way of upgrading to what is an existential crisis for crypto I think is uh is is it needs to be shifted because PQ is is the thing that we really need to be working towards. uh so uh in particular decoupled consensus the pub key uh registry uh for the PQ keys um there's so there's a there's a number of things I think in the upcoming and I that I think are are very important >> right yeah lots of important changes

like uh all around the protocol I guess that's uh that's interesting to hear yeah thanks thank you Matt yeah Nico what what are your thoughts >> yes so right now I mostly focus on Amsterdam. I guess uh that's the top priority just getting loadster ready for mainet getting the specs finalized in a few places. Um yeah and then forward looking I guess uh also worked a lot on Fossil which I guess is the main thing I want to see uh shipped fast. Um but also all the other what Matt already mentioned like the decoupled consensus is pretty interesting and also a just road map in general getting us closer to PQ readiness

um are interesting topics. Yeah. But currently fully heads down on claws and uh once we got that sorted out I think uh we have more room also to work on future folks. >> Awesome. Nice. Um yeah uh thank you so much. Yeah and before I hand it over be I mean I hope you guys prepared some questions uh for Metaniko here. Uh but before we get to that, I have one more uh question I wanted to ask. Uh and uh whether you have some uh something that you wish you knew uh a couple years ago where you were starting in the core development, you know, like when you put yourself into the position of fellows here, whether you have any advice for

them, something uh that you learned uh along the way uh that stuck with you. Um yeah, if anything comes to mind. >> So I maybe I can start with something. I'm not sure it's it's a good tip or something. But uh so initially I was really overwhelmed. Uh so I was really good in my previous job and like one of the top performers or whatever. Then when I started in Ethereum, I was like, "Oh I don't know anything." And like every problem seemed like it's hard to solve because you just didn't know so many things and then every time you try to solve an issue, right, you found some other parts in the protocol

you didn't know and then you spend so much time just learning about that part. But yeah, my my main tip I guess is that this is just part of the process. And uh once you dig through this stuff and just invest the time to learn about not every single piece of the protocol but like the relevant ones to your work um you will I guess how I always think about it your brain will start adopting a way of thinking about the protocol that feels more natural and then you also have a good intuition of like how to think about different parts and it's just easier becomes easier and easier over time um to work on the protocol even if

it feels really overwhelming like for me it was like the two first two years I guess was pretty um like I felt like I don't know anything now I start to think oh maybe I know it a bit but yeah it's a never ending journey I think to get better at it >> you know I think it's very telling that this was the exact same thing I was going to say So, uh, thanks for stealing my thunder, yo. But it's, uh, and I I can't, uh, I can't reiterate that, uh, more clearly. It's it's it's an extremely complicated thing that we

work on and there are so many different domains that are unrelated but utilized and there's so many different facets that they all tie together in this very elegant solution. Uh but the complexity is extraordinarily high with all of them. And it's one of those things that it is going to take time to master. And part of that process is it's a moving target because the protocol is evolving as you're developing your skills. So the things that you learn today may or may not be relevant tomorrow, but they are going to be part of that story that

carries you to where uh that uh that that next day is going to start. And just being able to to focus on one piece at a time, I think is probably the best advice that I wish someone would have uh I think would have been very helpful is that, you know, just focus on networking and like you're never going to get everything or just look at the state transition or uh just focus on peer management and just focus, you know what I mean? just take one piece of things and then really analyze that and then once you kind of have a grasp on that and you can make contributions to that one thing while you're learning and like

the learn as you grow and learn as you build and then once you kind of mastered that to move on to the next domain and kind of take it domain by domain uh it is a long it is a long road. So that's one of those things that I I I agree with Nico completely is it it no matter how smart you are because like you have to remember that the people that you're going to be surrounded with are also very brilliant, very motivated, very diligent people. And so even coming from a place where you are brilliant and diligent and and coming from the right place, uh you're running with you're running with athletes. And so it's an incredible opportunity in order to

challenge yourself. It's a credible opportunity in order to learn and grow. And if you take that as your uh your fundamental drivers that you're learning and growing and you may not be everything at once and honestly like I still wish I could have grown as fast as Nico like his understanding of the protocol is deep and broad and it speaks to his dedication and uh this is one of those things is that we can work in our own way in order to grow as fast as we can and as long as that's the framework that you work uh work within in uh you're going to do fine.

>> Awesome. Thank you guys. I mean that's really nice. I think very useful also very motivating and uh yeah I mean the complexity of the protocol requires some expertise and focus on a on a topic. That's what we try to do here in EPF like trying to get people to focus on a single project single domain and sort of own that because it's it gets very overwhelming otherwise. Yeah. Thank you so much guys. Uh it was really nice. Um so yeah, I hope you guys are excited. Uh folks, do we have any questions? Anything you would like to chat about? Uh lots of experience, lots of thoughts here. Uh Chris, go ahead.

>> Yeah, I have I have a few questions, so um feel free to answer whatever um you want. But um I guess uh from working on the builder with with Marco, it's it's been really interesting experience so far. Um, and I guess there's kind of two or three things I was going to pick your guys' brains on. Um, firstly, it's kind of coming down to like um, like collaboration. Like working in Ethereum is way different to like a big company because you're kind of working across like multiple teams and clients and you have to like think about like a lot of different stakeholders and a lot of different like um, I guess like priorities and things like that. So, I guess I was wondering like how you guys manage that. Like for me um even

gathering all the context and like relevant information about the builder took like a long time because it touched so many parts of the protocol. So I was wondering what your own process was for that. And then outside of that um yeah I was wondering how you balance like collaboration with other teams and other like key players on things you're working on and because people have like very different opinions and like care so much about the protocol. So um they were kind of my first two questions. Thanks. >> I guess the second one is easier to answer. So it kind of depends what the work is you're doing. Uh there's a lot of stuff that is like client specific.

So we usually discuss it internally. But even like in loadar we we try to have everything public so everyone can participate in the discussions like even external contributors. uh when it comes to like spec discussions uh especially like on the API um for example there are so many stakeholders you need to get an opinion from so yeah that just requires a lot of coordination um like a lot in the EF R&D discord just talking to other clients what they think or just proposing a solution on the spec and then getting like opinions from others um to get a consensus on that

Um yeah I guess following spec so your first question was mostly how do you follow everything or how do you keep keep on top of everything. Uh I think it's just um following the spec but I guess you first need to understand the spec properly to easily follow everything. I guess that's just a difficult thing to keep ahead of everything. Um yeah, what I do is I I have my bot or I have like a daily digest for Eve R&D channels that I'm interested in to give me like a daily update summary of what was important uh during the last day. Just like a twominut read for me and then I can see

oh there was a discussion I missed or something. >> Um cool. Yeah, that's that's interesting. I I set up a bot as well for builder and that's been like hugely helpful um for keeping on track. So that's interesting. >> Sorry Matthew I interrupted you. >> No it's okay. This is a very this is a very difficult challenge especially at first uh because as Nico mentioned there's there's so much information even when you uh are up to date uh it's hard in order to stay up to date um and it's just it it just takes the time to do it really is is the thing and there's so many different sources of information so

being able to like I think the exploratory phase of what's important is one of those things because you can't digest everything I think that's uh very few people have the ability in order to be able to process it all. Uh so finding the things that really matter to you. And this is kind of goes back to that domain specificity uh is if there's something that you really are interested in and just kind of focusing on the topics and discussions that surround that one idea and the specs that surround that one idea and the accessory uh specs and and uh like for instance the LIB P2P spec or or the builder spec or the you know there's a lot of other that are not the main consensus or or deals um and and just doing that one

small piece uh so that you have the the mental capacity to to uh not only learn what it is but follow the discussion in order to be able to start participating in that. And I think one of the things that is probably a key to success is not spreading too thin across all of the different facets because you'll definitely spin up faster if you do focus and then start to integrate with the process meaning actively talking. And that's one of those things that is very uh is very overwhelming at first because like you're you're talking amongst s uh people who have such deep knowledge on these very complex topics and nobody

wants to sound stupid. Nobody wants to say the wrong thing. And so being able to get up to speed to a point where you can actively uh integrate with the conversation at least on that one small facet will go a long way in order to basically get your name out there. And I think once people start to recognize who you are, even if it's just looking at the builder API or just looking at the the beacon API or just looking at the lib pedto piece back or and that will give you the credibility to start asking questions about some of the other things in order to accelerate your your knowledge in expanding into other facets of the protocol. And then once you get to the point where you're Nico and you

know everything and you know all the different bits and pieces like then you can start to digest it all because you have context in a way that like you don't have to figure out what the words mean no less what did the what did the sentences mean like there's going to be a lot of things that like equivocation do you know what I mean like what does that mean that word mean you're going to find a thousand words like that that you know what does that word mean as a word and what does it mean in context of this thing and then what is that thing and how Does that actually play into the rest of the protocol? And like that is just the part that like going deep in a in one small place gives you the credibility to start asking the questions in other places.

>> Yeah, that's that's super interesting. Um I think Marco was encouraging us to get on on calls as well just says that's a good way of sort of breaking in. Um so that makes a lot of sense. Um I guess my my last question um was just around more so like I know you guys have like worked on and authored um a lot of like specs and EIPs. Um and I guess I was just wondering like given like what you know about the protocol and like the many different directions it goes in like um sort of what's your process for trying to come up with a direction and not getting like paralysis analysis and you know because there's so many different ways you can do things. Um, and I wonder how you guys balance balance those

things. Um, yeah, thanks. >> Just build it. Like nothing you're going to do is going to be perfect on the first round and there's so many things that we built three and four and five times. Like we are in really at its heart we are in research development programming like we are a research and development organization. We are doing something we are we are blazing trail that nobody has ever gone down before. And there are a lot of times when uh like when you sail, you know, you sail into a bay thinking that it's going to you're you're going around an island and turns out that's a peninsula and you just don't know that until you and until you tack. And that's that's the same approach that you need to take is you

build it and it may not work and you build it again. And you may find that you get lucky over time. Uh and that's okay, too. and being able to accept the fact that you may not get it right and just do it is fine. Like that's a huge piece of uh because what we're doing again like there may be a best way to do it but there's a lot of ways to get it done and you won't actually be able to know what that best way is until you do it. >> Yeah, it makes a lot of sense. That's definitely been like our experience I think on the builder as well is like um you know we started with a plan and and like it iterates a lot just based on like what you learn through like

implementation and like talking with people and getting different opinions. So um I think like yeah I guess what I take from your point is sort of like be quick with execution but sort of fluid in in how you're you're planning things. Um, but yeah, no, that makes a lot of sense. Um, thanks for that. >> And also know that there is as much value in failure as there is in success because you either you win or you learn. And that's incredibly important in what we do. Like having that mentality that you win or you learn and maybe you need to learn something different in order to be able to do that next thing will absolutely take you a thousand miles

farther. >> Yeah, that makes sense. Nothing nothing's lost, I guess, in in trying something. So, yeah, that that makes a lot of sense. Thanks. Yeah, I think that's a big part of Ethereum R&D that there are many paths not taken. Uh lots of research, prototyping, development went to uh features that end up not happening, right? But it's a learning experience. It's like we learned how not to do it or like we explored different ways. So, uh definitely not to be worried about that.

Um okay, folks, do we have some more questions? Anyone else wants to chat with Matt, with Nico, feel free to raise your hand. Uh, I think a lot of topics you can you can chat about. Um, please, uh, oh, we have a question in the comments from Moit. In your experience, uh, was there time a bug made it all the way to mainet and how did it change the way your team tests or reviews code afterwards? Yes. All like tons of it. And like that's that's the part of the process. Like it is part of the process.

You hope that you can catch the big ones, but you don't always. And if you catch one that's a problem, you do a patch release and you just fix it and and move on. Like you hopefully will not make anything that's going to be a consensus failure. like you you want to not not take the network down. Um but that I mean looking at what happened at Fulu uh and the last fork you know there was there was a client which will go nameless I might add protect the innocent but there was a client that has 23 25% market share at the time and they had a bug and so we were you know within

8% of of not finalizing and actually I think it got down to less because there was a certain portion of the network that didn't upgrade right away. So, there was, you know, we were within a couple couple percentage points of not finalizing after the Fulu fork. And it happens, you know, it it does like you would hope that you catch them, but this is real life. Yeah. But more or less like um I guess always if there's a bug that slipped through to mainet which I guess I can't remember the last time this happened for us but but uh you always want to prevent this from happening again right like we

had a like our main issues we had in the past were like some weird native library we had that didn't support some old CPU or whatever that affected a few users and uh because that was just not covered in our testing infra. So I guess it's one example where we just added a script now that at least sanity checks this um since it's not that easy to test. But yeah, you you want to definitely always uh think about how can you prevent this stuff in the future. I think anything else is not acceptable. Like issue should never happen twice basically.

>> Yeah, agreed. That's a good point. Yeah, it's um it's a vast protocol with tens of users. There is always so many edge cases that are just impossible to account for. But I want to say like the whole testing uh infrastructure just evolved so much since like the merge like it's uh all of these uh new cases coming and just so much more uh infrastructure for that. Chris, go ahead. Sorry. Yeah, I I just wanted to kind of piggyback off that like um obviously like with AI kind of becoming more used in like development and stuff. Um is there anything you guys do now that you

wouldn't have done before just because of like the velocity of of like how quickly you like ship code now or or merge code? Um you know, in terms of protecting against bugs and and whatnot. Um, and then yeah, I'd be interested to hear like how your own thoughts on your AI development workflow and and like how that's impacting you for such a sensitive piece of software. >> Yeah, I guess uh so I use AI heavily to audit my code. So just trying to find edge cases, which I think now with AI, if you just spend a lot of time digging through the code to try to find edge cases, I think you can probably almost 100% prevent bugs if you do it carefully. Um, but also you can really

easily let AI do testing for you. So I what I do regularly is just tell the AI to come up with some configuration options or some like just give me a curtosis config I can run which before it would be a bit bit of a hassle to come up with all of this yourself. it takes maybe half a day to test something properly and now it's like an hour maybe have AI iterate on it and just try to find bugs especially like the the part where it's like reading logs and just it just runs for an hour and there's a lot of testing and before AI you had to sit down yourself and read the logs and uh you just have way more time now to focus

on the code instead of having to spend time on these tedious tasks. So yeah, >> nice. Yeah, very very interesting. Um, there's something else AI related I was going to ask there, but it's it's my mind, but um, yeah, that's super helpful. So, thanks for that. >> Yeah, we can get back to that. Um, yeah, thank you guys. Uh, yeah, do you have any more thoughts, more questions? Um, this is a Yes. So, I want to actually I actually want to address the that's why we need formal formal verification.

>> Um because that is actually kind of a spicy topic that we're talking about and I apologize to to cut you off Stephen. We'll we'll be happy to answer yours next. Um, and this is something that I think is kind of dovetales in with the AI discussion is like it is possible in order to do formal verification for parts of the codebase and uh and do which would give us better coverage than spec tests because it's all invariance but at the same time most of the problems that end up happening are not in the spec tested code paths. It's all of the caching layer. It's all of the

the multi-threading uh and and workload management and uh and uh uh in our case like native library integrations and garbage collection uh happening at the wrong time or hot path optimization or like there is so many other things that are far far more critical than formally verifying some of the uh potential potentially spec verified uh functions that it's really it's really difficult to say that that's going to be a panacea and I think it's also going to be a significant amount of time between now and at some point in the future when AI

can actually do the this development because even on our own team uh there is a huge huge gap between the people who lever AI very well and the people who are less good at levering AI and I might add everybody in our team is very good. Do you know what I mean? So like there is an even bigger gap between the people who vibe code and and the people who are excellent at levering AI and you still need to have the the the squishy gray matter between the ears in order to get the AI to turn out quality code. So, I think this is something that is it's very important to be able to read

the read the tea leaves and honestly smell the that the model comes up with because most of it is just like it makes up. >> Yeah, that that was actually my question around formal verification. So I think I read a post by Vitalik recently on on sort of AI development and one of his points on formal verification or at least what I took from it was that it's only as good as the person who's creating the invariant around it. So like the issue is not formal verification itself. It's can you actually come up with the invar invariance and like the issue is people say form if you can formally verify something it's fully secure but it's only as secure as as the invariance you can come up with and I I suppose some of

the worst attack vectors are um you know the things that people don't think of >> like most bugs in software are buffer overruns or or memory uh memory reads like array indexes like you know like that's that like AI is good at that stuff, but at the same time like it's it's it's not so simple. Like AI is been a great great tool and it's an incredible force multiplier, but it does not replace the job of software development. At least not yet.

And and honestly, after seeing the most the latest frontier models, I think it's going to be a while. even did you wanna Sorry mean >> let's go to Stephen when he's been waiting >> yeah okay hi hi guys uh yeah I was wondering like what surprised you most about uh how the Ethereum core development work uh process actually works compared to how you imagine it from the outside and also I want to know what was the like the the turning point

that made you decide to contribute to the protocol to turn like full time. Yeah, that's that's my question. >> Okay. So like before I was a core developer and kind of got to know a lot of the other people in the core development community, it was this this what seemed like impenetrable wall of of like super ninjas and uh like very much put them on a on a a pedestal. Um which I think sometimes I notice when when people like oh what do you do? they actually know what Ethereum is and you say I'm a core developer, they're like, "Oh my god." You know what I mean? And um and the funny thing is is

now that I've kind of got into it a little bit more, I realize we're just like a bunch of nerds who like to who like to code and and uh we're we're we're just as fallible. We have just as many, you know what I mean? It's uh it's been enlightening to realize that there are just a lot of really talented, kind people. Uh but they're just kind people and and uh anybody can do it. You know, if you want it enough, anybody can do it.

>> Thank you. Thank you so much. Okay, before we get to another question by Chris, we have one in the comments about Death Star. Could you walk us through what that Death Star actually is under the hood? Is it more of a coordinated fault injection cause engineering harness or closer to a fuzzer targeting specific client behaviors? What kind of failure mode is it aimed at uh surfacing? Yeah, very cool name by the way. >> Yeah. So for the name I have to credit Barnabas. He was the one that came up with it. I think my initial name was like rogue star or something something bad. But uh but yeah, so it's not a fuss or similar to that. It's a malicious

loadar node that just does some like um malicious um behavior as like a validator or as a proposer. Uh so um there's a lot of um behavior especially in GLAS where it's like okay you can reveal a late payload late or you can withhold it or you can try to reorg a block you shouldn't be allowed to reorg that was the initial uh edge case I tried to test on the defnet because there were several clients that didn't have their fork choice implemented correctly so they had tested incorrectly and with death star tried to basically reorg a full like a timely payload and and Dev Star would always try to reorg

it and that basically tested if every other client in the network like Nimbus, Prism, whoever um that they vote correctly and their fork choice um works as per spec and not as some some incorrect behavior that would be unsafe to ship to mainet. Uh so that's a lot of these uh edge cases. It does a whole range of other things now like doing two proposals in a single slot and uh yeah just trying to find edge cases in clients. Um, at that point I I don't expect anymore that it breaks other clients, but it's uh some nuances how uh clients attest and how their fork choice works and if they handle these cases

correctly. >> Cool. Um, >> yeah, thanks Mario. Um yeah, I was I was going to ask um kind of on Matthew's earlier point about software development with AI like um where do you see sort of your roles going because I kind of see like many roles compressing into one and ETH is a pretty good example where like take the builder for example like you need to know about software development and economics and game theory and like other things. So, I'm wondering, is that where you guys see your roles going that you're going to become like um sort of experts in in all of these different areas moving forward? Um or do you see

like sort of your role evolving differently? >> No, I definitely do uh agree with that. Uh I think AI the one thing that AI is going to be very difficult for uh initially is junior developers because uh what really separates uh a junior from a senior from a staff engineer from a uh you know from a principal engineer is that uh higher level projectoriented big picture thinking that only comes with time. like you just have to know more things in order to be able to take more things into account in order to be able to look at the big picture and some

of the stuff you're talking about is like you guys are working on a particularly complicated project and you have a very very very good proto one of the best protocol engineers in the entire protocol who's helping you and shephering you. So the ability to, you know, you have a great resource in being able to look at all of these different very complicated facets that that come into what makes the the builder uh uh what it is. Um but I think that is a parallel for uh what's happening in the software industry as a whole is that you have to kind of understand architecture.

you kind of have to understand DevOps and and because I think a lot of the junior roles just you don't need as many like because you can have 27 agents working for you and it's very difficult as a junior in order to to be able to smell out the pardon my French, of what the AI is telling you. And like that's the part that's really hard is that it can literally lead you down a rabbit hole that you don't even realize is a rabbit hole. And this is where the like the people who have cut their teeth and have gotten into, you know, a senior role uh because they've learned that stuff I think are the ones who are going to benefit from from the AI revolution. And I really do see it as

an issue for the industry and and not just software. I think the same thing is true for lawyers like because you don't need parallegals. I think the same thing is true is for accounting because you don't need to have juniors that do that. It does a lot of the basics like and I think this is this is really a big risk in the economy is that the younger people today are they they're missing that rung on the ladder in order to be able to get to the next rung and being hungry and driven or having a great opportunity to talk to somebody like Nico regularly uh you know it's it's a huge benefit.

>> Yeah, I totally agree. I think like most careers now are probably going to have to integrate like internships like several internships into like college programs or whatever going forward because it's just going to be impossible otherwise. Um but yeah know that makes total sense and um yeah that's definitely what I'm I'm feeling and seeing on the ground. So um yeah I agree fully. Yeah, recently I saw an article on Hacker News about exactly that. Like it's basically the hardest time to be a junior deaf or like just generally in the economy I guess looking for a job and then like uh just the uh the lowest parts of the letter being letter being

being replaced by AI. It's uh it's a tough time. So uh yeah uh that's why I also believe maybe the fellowship here helps people to actually develop real skills. Yeah. >> And use AI wisely. Um okay folks we got uh another 15 minutes to go. We got bunch of more people here uh that I would like to hear from. I'm uh I hope you have some insightful questions. Please do raise your hand. Feel free to ask Keshov. Go ahead.

Yeah. Uh, you're muted. >> I think you're still muted. >> Yeah, if you are. Yeah, if you can hear us, maybe you can also use the uh chat if your mic doesn't work. Of course. >> Huh? >> Am I audible now? >> Yep. >> Yeah. So, uh my question was regarding the prototyping. So usually when you are in the prototyping phase and uh alongside the spec is being built and pip are being implemented and you have

the urge to help and contribute uh to build a certain uh at a certain checkpoint. So there is some progress uh built and some things to show for so that uh it might it might help cold devs later on for that particular thing. So how do you really uh go through that everchanging spec and also make decisions on how that prototype must look like? Uh cuz right now uh uh currently we are working on optional execution pros and the spec of the optional execution pros are quite updating very frequently. So

that is why I had this question. Okay, let me if you don't mind, let me repeat that back to make sure that uh that we have that is and I see Nico might might want to answer it. So um the idea that prototyping is something that happens while the spec is being developed and how do you preserve the information that was uh that was learned through the prototyping process when a spec may not be fully uh fully merged or or is still going through review or an EIP is in progress.

Is is that correct? Yeah. >> Did you want to take that, Nico, or do you want me to? >> Yeah. I mean, in my mind, like a prototype is for me mostly it's just uh I want to give feedback on the spec and I want to understand the spec better from an implementation side. At least from my side uh it's for me it's way easier to reason about the spec if I actually implemented it. And then I can also see okay this is how it looks in load star and maybe then I can estimate the difficulty of actually what it means to ship this to mainet. Um which sometimes like from a pure spec perspective is not clear. Um so that's

the main goal for prototypes. Um I did so many prototypes that I threw away again. Uh this just normal I guess. Um but yeah with AI now you can also iterate quite quite fast and uh um but yeah I think the goal of the prototype should not be to just copy paste the spec with AI and then just see if it works but really to look at what code it produced and to give feedback on the spec side. Um that's I guess what's valuable in the end >> and that is actually what I was also going to echo is that um the prototype is not like you shouldn't be prototyping with the uh with the the end goal that

that code will end up getting shipped to main uh and it might just get iterated on like really prototyping is there in order to give you enough information to refine the spec and if the prototype is built and you realize the spec is good just commenting on the spec and just saying hey this this worked pretty well and here's a branch that I have gonna throw it away but and that's a very common thing like I think uh the most important uh contribution that can be made the highest the highest level of contribution that can be made uh in the Ethereum ecosystem is being able to contribute to the specifications and the the the protocol because that is the

core protocol and not just lines of code. The the last line was thank you so much for the feedback. >> Great. Um yeah, thank you. Thank you for the question. Nice. Um yeah, anyone else guys feel free to raise your hand or write in the comments. Let's keep it going. Um I think a lot of things you could discuss here about the bunch of topics we already mentioned earlier, the future, the postquantum thread, the uh

the past experience like combining years of these two guys. I think you have bunch of things to learn. So feel free to ask anything you are curious about. Um, >> I'll uh I'll jump in again if if that's cool. Sorry, I'm asking like a billion questions. Um, if if no one else is. Um, yeah, I guess two other things I was interested. You mentioned like quantum resistance earlier. So, I was wondering like what are kind of some of the threats to the protocol you guys are most I guess concerned in or concerned about or think are like interesting engineering problems. And then on the flip side, like what are things coming to the protocol that you think are like

most exciting in terms of actual like real world adoption or just features you think are really cool or like nice quality of life things that are coming soon that you are excited for? >> Yeah, I can maybe quickly talk about the features. I mean this just my personal thing I like to see in the protocol which is like uh stuff like encrypted man poolools. So we combat MEV and like the private autoflow uh that currently exists on Ethereum. Um I think this would also really benefit users in the end. Um if that problem is resolved and then just the whole privacy development

like having protocols like rail gun um getting like polished or like sorted out and maybe even natively on the protocol layer while like frame transactions and just um I mean this is a lot of work on the E side, not really the CL side also. Um yeah, other than that just um getting a better consensus algorithm like decoupling consensus and uh coming up with with stuff there is interesting for me. Maybe Matt has more stuff on that.

You know, I do uh I'm I'm really uh I'm really bullish on account abstraction and encrypted me pools. Uh so I think that like making the experience uh better for someone like my mom uh who doesn't understand what keys are and and has no idea um and it's going to be even more complicated once we get to the world of PQ. Um I think is something that is for from an adoption standpoint I think is incredibly important. Um, for the PQ roadmap, I think there are a couple of difficult engineering challenges and one of the ones that I think really has gotten no love and I think will become very very important um

and might actually be outside of the realm of just Ethereum is uh how do you do postquantum for TLS and SSL like SSL breaks uh when you get to PQ? Uh so how do you actually do secured communications uh to your bank account to uh you know not just peer-to-peer networks uh in a way that's fast enough that really works. Um and uh I think the upgrade path from uh BLS keys to PQ keys is going to be fraught with some challenges. That is there are some very complicated nuances to that that have to be uh that have to be resolved because ultimately at some point you can break

the BLS key. So like if you haven't upgraded in time, you know, then what are the fallbacks for that? And there's just a lot of other details like it's actually a discussion in the Bitcoin world is what happens to all the all the accounts that don't get upgraded and all the you know all the BTC that just is sitting there vulnerable. Do you burn it? Do you do you use it for development? You know there's just and those are social challenges social engineering uh uh and consensus issues which are much harder to solve than the technical challenges. Um, and I think the biggest thing, and this is I I'll give you a little spoiler here. Uh, I'm going to give a talk at um, at E Taipei, and I think this is the

heart of really the part that makes me most excited. um is people are so concerned with the financialization like everything is a new DeFi protocol or a new way to monetize or a new way in order to essentially extract value or or do rehypothecation or and to me I think that is something that is it is antithetical to why we at least I know me and why Nico joined is Ethereum is a root of trust. It's about privacy.

It's about sovereignty. And there are so many other things that there are so many other use cases to blockchain technology that are not explored because there's very little value in them or at least there's very little financialization and value extraction value. Like memecoins just about taking money. It's a it's a it's a gamble, you know, and that was what the ICO boom was. Most of those things were junk. Like there was no real utility there. And I think this is the paradigm shift because many of you may end up doing protocol development. But anybody who's sitting on this call is of the best and brightest and most diligent people in the space. And if you don't end up doing protocol development, I

would venture to bet that you guys will move on to doing something in the application layer on Ethereum. And this is the part that I challenge you is can you find the use cases that root of trust really matters. Like money is an illusion that only becomes real if we all agree. And that's why we build blockchain technology is so we can all recognize that this is money because we believe in it and we can we can create this synergy uh without having to trust somebody that prints the money. But there are so many other use cases for trust. Whether it be supply chain or it be um uh credentiing or digital identity or government accountability or like on

and on and on. I mean, you could create a decentralized insurance broker that you put your you put your money into a risk pool and then that gets paid out as claims are made and like that could be smart contract protocol like smart contract builds or real estate investment trusts or there's just a whole range of ideas when it comes to what do we use trust for in society that don't require or or have no bearing on DeFi or value extraction. You literally don't need an L2 for it. You just need to store root of trust for a database.

Like there's so many little nuances. And that's the part I think that is most exciting and most important for not only Ethereum but for the entire ecosystem to to be able to be the tool that we built it for. A tool that breaks the incumbency between wealth and power. That was pretty cool. That was a good speech. I uh yeah, I agree with all of that. Um I I was going to say h your point on sort of like how do you get funding for things that really matters is definitely something I'm I'm really concerned about because um like there's been several projects I've worked on now that like create great technology but um funding them is is really hard even though

they're like really really needed. Um, so I'm really interested in sort of experiments that ETH is doing to sort of focus on public goods funding for things like that that are like ne necessary. Um, and on the privacy front like I think PSSE is doing some really cool stuff. I've been following I think they've revamped the like Macy project and stuff. So I'm pretty excited for that. Um, but yeah, that was great. Thanks guys. >> Yeah, that was really great. I think like I mean we are at the top of the hour here but yeah, thank you so much Matt. I think it was a really nice nice pretty motivational speech there at the end and uh I I really appreciate this coming from from both of you guys. I mean I really feel that you guys are in for the for the ideas of sovereignity,

freedom like this is all about and uh I mean that's why that's what keeps us going here. So, um that's um yeah, it's very exciting to hear and um yeah, I think it was a really nice uh nice way to um uh to sum it up here to to wrap up for today and I just want to say again uh thank you so much for joining us. Uh it's been it's been an honor. It's been really really nice to hear from both of you. I think uh educational, inspirational, uh very uh very great indeed. Yeah. Thank you so much.

Yeah, thank you for having us. It was really nice talking. >> Thank you very much. >> Yeah, awesome. Thank you so much both of you and uh thanks for all the fellows who made it today. Thanks for the nice questions. Chris, thank you so much for carrying it. It's been very active today and yeah, I'll see the rest of you guys on on Monday for the for the next EPF call and uh yeah, thank you so much everyone. Uh it's been great. Have a great rest of the day. >> See you guys. >> Bye.