EPF7 Office Hours - Will

recording is on.

Okay, awesome. Seems like it's working this time. So, yeah, let me uh again welcome everyone. Thank you so much for joining our office hours call today and especially thanks to you, Will. Um yeah, great to have you here.

Um so, our special guest today is Will from Ethereum Foundation uh protocol coordination. Um I uh um I'm very grateful that you could make it today. uh very special guest uh maybe with a bit more different background. So like I'm uh I'm excited for the fellows to meet you and uh learn about your perspective on things. So uh yeah uh before we get started uh just for the fellows to get to know you uh I will start with a couple of questions and u first I'm curious to hear more about your background.

I think it's it's very interesting uh how you what you did before Ethereum what eventually led you uh here. Um yeah, just tell us about yourself.

Yeah, thanks for having me, Mario. Um yeah, so I, you know, crypto did not exist when I began my uh my professional journey. I'm quite a few years older than most other people. The internet hardly existed when I started that. Um so I started off as an architect.

Um, I would design buildings and uh did architectural design and uh construction management and real estate development for 15ish years. And my partner, significant other, she was also an architect uh started, you know, we've been together a long time. started off in it and she ended up getting more and more into development uh web development and engineering and you know really like I started off being in architecture by you're kind of drawn to like hey I want to work on the things that people spend time in and like experience and like have you know have life experiences in and um at the time it was buildings and really like as my life has gone on it's become the internet more and more. Uh, and so I think that she was drawn to that originally. And then I learned I'm just very uh drawn to process and trying to help like put people in a position to be successful and through collaboration.

So there's a saying that architecture uh is the mother of all collaboration. like this was the first shared art that people had to work together on to be able to like create some type of shelter or civic uh you know temple or or or building to bring people together and so yeah a lot of trades and arts um were born out of out of the need to do architecture. So anyway like yeah real interest in in process and architecture or process and collaboration and so when I saw her start her uh journey into development she started off working in a scrum focused organization and it was very agile and it was just completely different um than the project planning that I was doing. it was uh you know architecture and construction are quite uh slow professions and there's a lot of built-in friction and stuff and so I just became drawn more and more to the technology side the collaboration side the agility and yeah I just sort of kept building year after year um and then she ended up going and becoming a co-founder of a Bitcoin wallet and I found myself just like walking away from architecture and and joining mean um another foundation that's for a Bitcoin side chain uh called STAX Foundation and the STAX is a side chain. So I was working on that um doing ecosystem uh core dev development uh uh core dev coordination essentially and um yeah the further I got into that world the more I started to formulate some thoughts for myself in terms of what parts of the crypto landscape like really uh spoke to me and and Ethereum was always you know very very uh I guess compelling in terms of the sheer breadth of the scope of the project, the scale of the intellectual diversity, all the competing ideas and mind share, the like rich ecosystem of a lot of different businesses and entities and organizations.

And as someone that's a coordinator and like loves air traffic control and stuff, I was like that's that's like max complexity. I need to I need to get into that world. And so I cold called Justin Drake and um managed to uh find myself uh working very closely with him and uh working on a lot of uh key coordination efforts around uh early Beamchain and to lean Ethereum lean consensus client development. Um and then also simultaneous to that uh a lot of ZKVM and uh L1 execution proving um efforts called ETH proofs. And then um yeah through that and sort of getting very familiar with the core dev environment um and the EF uh organization.

found myself uh stepping into this new cluster coordinator role uh back in April and so doing that now with uh Frederick I believe maybe was here a few weeks ago. So uh really more security-minded uh and uh engineering you know quality assurance and then with Kev uh Wedderburn who's uh very very sharp in terms of his understanding like kind of comprehensive understanding of the execution and consensus layers uh both past present and future and uh sort of the research to um development pipeline. he's, you know, also very very uh adept in. So I think the three of us have managed to sort of split the role into like just sort of an internal like I'm like the head of operations kind of person. Kev is the head of R&D type person.

Frederick is the head of engineering uh type person. And so those are more like internal uh operating titles rather than external facing ones. But it helps us like understand who who's doing what and who has coverage over what kind of tasks and things. So

Okay. Awesome. Well, yeah. Uh uh thank you so much for sharing that. We are already getting into uh your current position but uh maybe let's take a step back.

I mean thank you so much. Yeah. Uh actually very excited to hear about more about your background. I mean I didn't know that for example you worked on stacks which is really cool. I I I know the uh guy uh Munip uh I think the founder or uh the guy behind it.

We invited him for a bitcoin conference like five years ago. I remember him. So that's that's that's uh yeah interesting connection there. But I'm curious to hear maybe about like your experience in this like so basically going from like a real architecture to protocol architecture sort of a thing or like starting in Ethereum and I always felt that you really got up to the speed really fast and uh like uh you work on uh pretty advanced research stuff directly with Justin as you mentioned. So I'm curious what was it like this experience of uh just getting on boarded getting you know thrown in the water I guess and uh uh yeah what what were the the struggles how you how you dealt with all of that?

What was it like to start? Yeah.

Yeah. Um, you know, I guess I suppose that trying to figure out like where to penetrate the research landscape or or what you're working on um is very challenging within Ethereum. I mean, it can be very intimidating and daunting. Um, and I think like having you figuring out like uh at least trying to divide, okay, I'm going to focus on E related work or CL related work is a good way uh to do that. And so you have to be able to be willing to build like a a mind map of who are the people, places, and things that you need to to work with to better understand that landscape.

And so, um, you know, there there's like really the the rituals of of shipping a hard fork and like that can be broken down into the weekly or bi-weekly ACD calls. And there's seasons that you go through for those ACD calls, whether it be um, you know, sort of debating in a headliner to looking at the proposed for inclusion window into the debates around tier lists that we're going through right now. and then into scoping. And so there's um really like you just got to figure out what's going to be your entry point. And if you are a specialist um you know that that I think that you're probably going to have like a much different approach to things than I would have.

I consider myself much more of a generalist. Um, and so like the value that I bring to this is like trying to be able to connect dots, unblock people, um, help Justin always says I'm I'm a lubricant, like trying to help, uh, things happen faster in terms of removing friction or blockers. Um, and so really I think if you're um a specialist like trying to figure out who are the generalists that I can rely on and can help put me in a position to be successful and can help um open up doors and connect me to the right people is probably a really good thing to do. And then if you're a a generalist like myself, you know, really just trying to understand a a couple of different uh points on the landscape and then keep building out from there until you like can hopefully like fill in the gaps and build a a little bit of a complete picture. I mean, it's always getting finer and finer degrees of fidelity uh to it, but yeah, I think that's what I would recommend.

Yeah, thank you so much. Um, yeah, that's uh I think it's a good advice, but also just yeah, exciting to hear your experience. I'm sorry, my camera is going going off. Anyway, um, yeah, I think it's uh for people especially here starting in the protocol from different perspective. It's very exciting to hear, but I'm also curious now you already talked about sort of your current role uh but uh how do you see uh maybe the future or your impact or maybe what motivates you?

excites you about the future of the protocol like uh we see many changes the storm map a lot of lot of evolution but um yeah I'm curious what keeps you going what uh um yeah uh what excites you about the the future of the protocol or upcoming stuff

yeah I mean it I feel like a lot of responsibility and the role that I'm in um you know there's just thinking about stewarding the the health and sustainability of protocol cluster which is my top priority. um trying to make sure that you know we're a functional like a functioning well functioning organization um that's conducive to engineering excellence and so I think you have to have like the goal is to sort of uh provide calmness and predictability around operations to the people that you work with so that they focus on the like the difficult tasks that they all focus on and so that that's like one meta uh thing that keeps me going and I think trying to do that in the face of so many different changing landscapes is particularly challenging um which I like a good challenge and like those landscapes are as you alluded to the the straw map just the research roadmap that's happening there's um you know obviously like great ideas are always emerging and new technology ies that dramatically change the road map um are quickly being derisked and and advancing. And so like we're getting all these gains from AI and formal verification uh in particular uh as an example and the like uh overhead for ZK VMs and and proving and you know being able to like generate uh zero knowledge proofs for a lot of different reasons is becoming more and more feasible in many different ways. Um, and so there's like the changing landscape from technological tailwinds, but then there's also the changing landscape from technological headwinds. So AI is obviously like creating a whole new security vulnerability landscape and and you know threated you know vectors.

uh it's flooding the team's uh issue and PR inbox with a lot of AI slop you know like coming their way and so like trying to discern okay what's a real emergency versus like you know just a bot um is becoming difficult and then quantum is the big uh primary concern and so I think that in terms of like our fork planning and our multi-fork planning um we're focused you know it's like we've the straw map that's the technical road map that we want to execute on and we've got the mandate which is the sort of governing b uh governing document that you know sort of helps us align philosophically speaking and helps us ensure like are we being successful or not like that's our success criteria is providing those asurances and so crops as I'm sure you all have talked about the s and crops is security and I think uh quantum preparedness is uh like everything else goes out the window if uh you're if all of a sudden there's a quantum computer online and uh we don't you know we're not able to uh verifiably prove things and uh cryptographically signed uh blocks and and signatures because everything's built built on elliptic curve cryptography and quantum computers can can break uh elliptic curve cryptography. So uh we have to have a very uh detailed accelerated plan to be able to act on that. And so there's yeah motivations at all different scales whether it be daily, weekly, quarterly, forkly or like this multi-fork uh motivation of quantum readiness.

Yeah. Awesome. Thank you, Will. I think it's an interesting perspective. You kind of like uh the angle that I that I feel here is like sort of like preparing for threats, right?

Like it's also one of my questions like what are the threats in the future, but I see that uh this is the stuff that you mentioned. So basically, yeah, being robust and prepared for for everything. Uh thank you so much, Will. Um yeah, uh very cool to hear from you and I would also like to hear from the audience. So like I think we got enough intro and uh you guys or maybe someone who joined bit later here will is the coordinator of the protocol.

So if you have any questions about the protocol, the coordination, the future, the past, the stroma, the ACD, um or will specifically uh his journey uh please raise your hand or feel free to write in the chat if you don't have a mic. Um I would love to uh hear some of your questions, some insights. uh please do ask because I don't want to keep will for myself. We can chat uh many times. Yeah.

Anyone? Well, Will is also one of my people who helped to Oh, okay. Kesha, go ahead.

Hello. Will hello Mario. So, I had a question uh very related to AI. So uh re uh a couple of months ago I went through Justin Bragg's podcast in which he mentioned that AI is something which is very fast. It can do a lot of things but having a human in the loop really helps you think through the problem like what they are trying to do with all the uh postquantum uh break tests and everything.

Uh so what I wanted to ask you is with all the advancements that uh is happening in AI uh how is the Ethereum ecosystem trying to adapt to it every day with so many people to coordinate with it like 350 people who coordinate with each other to uh see look uh how the progress is being made. Uh so how do you uh coordinate and do all those things uh which is uh quite baffling because uh we individually working on a very small problem as an EPF participants and we quite get overwhelmed with all the things there is to know when we are going with this process. So wanted your uh advice on this and some thoughts that you might have on this. Yeah. Uh, thanks for the question.

So, I mean, AI has been a lifesaver for me in a lot of ways. I mean, I use it a lot. I uh, you know, personally have a probably a much different implementation use case for AI than a lot of the members of Protocol. And so when you look at um at protocol maybe can I share my screen for a sec?

Okay. So yeah maybe it helps just to see what the orb chart looks like. And I don't know how large that is if that's helping out. Okay. There you go.

So, is that coming through?

Yes. Perfect.

Yeah.

Okay, great. So, yeah, as you can see, there's a lot of um there's about 60 people that are in the protocol cluster. And so, I always think of it, see the orange outlines, I say that's the left side and then the purple, that's the right side. And so really the the left side are more research and development and then the right side are more uh engineering and mainet readiness security um things of that nature. And so when you look at the straw map you can see that there's five forks laid out over time.

[clears throat] And so over time any one idea has to go through what I call like a maturity pipeline and yeah here's maturity pipeline. So if you think about you go from research or an idea all the way to an EIP and then a lot of times you know uh before teams are willing to consider an EIP they have to see a working prototype of the EIP and then you know say you you get some people excited about your EIP and some teams start building an implementation of that. You can see it in a devet environment working on it's like the working uh mainet version of Ethereum plus your EIP and so you can see the implications and performance of your EIP and then that starts to convince people and they say hey we want to propose this for inclusion into the next hard fork now it's like gets into considered for inclusion and then it gets scheduled for inclusion until it finally reaches mainet and so you can kind of see that based off of those colors outlining there's different activities that the different parts of the cluster um generally speaking are working on. um it's not so like binary but anyway so throughout like the the horizontals if you will of those different modalities of working and then the the verticals of research uh areas of inquiry AI becomes uh very useful in a lot of different ways. So, um, let's say you're in, uh, architecture and you're a researcher and you're thinking about like nearfork improvements.

You're going to be using AI to pull mainet information and uh, sort of clean that data and look at it, you know, in a bunch of different ways. And maybe you're going to use it to synthesize a lot of feedback from different people and ideas from other folks um into like a summary that you can like better digest and understand and and then use that to propose an idea. And if you're in research engineering, um these are people that are taking ideas and like really taking new and novel technologies usually around ZK VMs or formal verification and trying to uh do a lot of um like d-risking of something that is fairly invasive that you're going to add into the protocol at a later date. And so you're using AI and like all these other different ways. um versus cryptography.

Every team on this on this list um you know has like their own special use cases that uh AI is really like a value ad to them in their own way. And then like myself as a coordinator really I'm using all of the time to help um transcribe meetings like do a lot I mean there's just a lot of action items that I have to do a lot of things I have to track um a lot of spreadsheets I have to make in order to break down problems and track costs or resource management things of that nature. And so, you know, I'll I'll use it in a pretty different way, but um yeah, like even just vibe coding a a quick website that you're going to use to, you know, have for an event or to show, um, you know, to try to promote an idea or something along those lines. Uh, it can be used. So, it's really uh it's been a real gamecher and it's um I think a an accelerant in a lot of different ways and um it helps like when I was an architect um architecture like the practice of being an architect is a profession that has a very long lineage of apprenticeship.

And so within apprenticeship, you are the apprentice and you're also the the mentor. And so, um, I spent a lot of years having delegated to me. People like marking up drawings and handing them to me and I've to just like do the grunt work and pick it up, right? But then I also got to be the person that I teed up a lot of work for interns that were working with me to like go and spend a week or two like doing it. And so being able to take like uh grunt work if you will uh that requires a lot of time and effort but not a lot of bandwidth intellectually speaking and describe it into a way that someone could then like go and do that work for a week is really good practice for prompting and uh being able to work with an AI to say hey like I'm anticipating I've got this to do this is like uh a time intensive bit of work that really I have higher and better you know things that I need to be or more important things I need to focus on and using uh I always like to think of these AIs as like interns that I'm I'm working with so thank you will um that's a very interesting point of view because um I'm not sure if you know EPF before it was EPF for the first two cohort it was called CAD have the cord uh apprentice program basically.

So uh I mean we call them fellows now but the idea is to like have apprentices for the cords. Um so yeah I think it's u it's very nice that you're I understand this this apprentice culture that's uh what we are trying to do here and I would love to show you my cool apprentices here. So guys, if you have any cool questions for Will, please continue. Just raise your hand. Feel free to write in the comments.

We would love to hear from you. Um, it's your time to shine. It's not not up to me to come up with all the questions, guys. Oh, Charles, go ahead, please.

Hey, Will. Uh, I I was wondering, you know, you mentioned ETH proofs. What do you think ETH proofs needs to show uh before we can confidently say proving is production ready for Ethereum? Yeah. Um, another building metaphor for you.

So, uh, this is something that I like to talk about a lot, but I always thought of ETH proofs as a public private partnership. And so in the world of like re I live in New York City and like in real estate in New York or uh building buildings in New York, there's like certain things that like you need the private sector to be able to or sorry you need the public sector to be able to come together. Hey, we've got this unique problem of a public library and elderly housing, right? Needs to come together and we need to remove all this red tape. uh to be able to like help with the guidance on the zoning.

You know, it's like a very unique situation. And then you've got the private the private sector that's willing to be like, "Hey, we can accelerate that and help you get that out of the ground and and build it for you because we bring all of this uh all these trade skills to the table." And so the metaphor that I use that with regards to ETH proofs is ETH proofs is like the the interface between the Ethereum Foundation researchers and what they are converging on for the definition of real- time proving like real time proving is a very dynamic subjective um everchanging phrase right and so that real time proving definition is informed formed by like you can you can prove Ethereum blocks you know in the blink of an eye if you use data centers with you know 400,000 GPUs banded together right that's not the future that we want for Ethereum we want it maximally decentralized so the first wave of guidance that researchers put into ETH proofs and what real-time proving meant was hey let's have a a cap on how any the overall cost that should go into a proving cluster of $100,000. Let's have a limitation on the amount of power that should be consumed need to be consumed by or to power a proven cluster of 10 kow. And so within there, you know, now we can prove an Ethereum block, but we've got constraints that aren't going to lead towards centralization.

And then we need to say, all right, it's got to have 128 bits of security. It's got to have a proof size that's 300 kilobytes or smaller. It's got to have livveness like it it needs to be submitting proofs and not offline at like 99.9%. It needs to be able to submit proofs within the 10 seconds within a slot that you need to produce blocks within so that you still have enough time to gossip those blocks like 95% of the time in order to like have the amount of coverage and assurance.

And so [snorts] ETH proofs has like grown over the years to like continue to respond to this guidance that we're getting from um from the researchers and then also like working with the the proving teams, the ZKVM teams, you know, to to basically, you know, hear their feedback and show metrics in a way that that makes sense for them as well. So it's not just like handed down. And so, you know, like some of our big challenges at the beginning were we need to make sure everyone's open sourcing this stuff. Like there's not a real incentive for these teams to open source and and collaborate and have their GPU prover and their verifier be open sourced. And we need to make sure that the proofs that they're submitting are actually verifiable.

And so, uh, you know, all of the all of every time you update approver, you have to update the verification key on ETH proofs. And so, when you send in a proof into ETH proofs, it will automatically verify it and you can download it and you can verify it. Um, so that we know that people aren't just like submitting empty, you know, blocks of numbers and and looking like they're highly performative or performant. Um, and so, yeah. Anyway, it's sorry to ramble on, but um it's a it's a dialogue and it like kind of evolves over time to keep pushing the industry in the direction of what's the most um well-rounded version of what real time proving means.

Not just along speed and performance because that has like you know negative potential in terms of centralization and lack of security and so you can't just optimize for any one thing. You have to like kind of approach this from multiple points of view.

Thank you.

Nice. Thank you Will. Um love that you elaborated there like it's a big uh complex issue I think like very exciting uh proposition of features there but also the centralization risk of big provers it's a it's a big discussion so yeah thank you so much for um getting us through that and folks do we have any more questions I think more about the research or will SCAS go ahead my man

um yeah thank you will for your time actually yeah I have a question about the research what would you consider the most underestimated area of research for theorem currently and why? H uh most underestimated area of research. That's a tough one. I mean, I think that there's um there's research in like I think that there's um big paradigm shifts that will happen like say going from a monolithic execution client to a ZK VM and like within there there's a lot of different research that needs to be able to happen um to be able to like optimize the proof systems for for that to be able to happen and to be able to um you know h have the assurance that you need. I'm trying to think of like one particular form of research that I think is underserved possibly networking.

Um, I think that there's a lot of um there's a lot of uh I think potential um bandwidth that can be saved and overhead that can be gained by chunking data in more efficient ways and um and networking clients and different uh you peer networks in more efficient ways. And um yeah, I I only say that I mean I don't know that for a fact, but directionally I I think so because the networking team at the EF is so new and obviously we're a peer-to-peer networking um software, a decentralized software platform. So networking is is key to what uh what we work on. And um there's something that's being worked on called ETH P2P which is like a purpose-built version of the networking stack for Ethereum. the current uh version of the networking that we use, LID P2P and dev P2P um are I guess fairly old and were um more like industry standards if you will that were uh you know like implemented in Ethereum and the funding landscape around the maintenance of those libraries has changed.

very dramatically in the last 24 months. And so I think uh there's a lot of incentive for Ethereum to develop and maintain its own um proprietary networking standards. Um yeah, so that's probably the area that I would say and I think that like um you know with decentralized inference and cloud computing and like there's a lot of u there's a lot of research and parallel fields that you can draw from to be able to uh find inspiration and uh model you know uh like borrow ideas from um which is also pretty interesting.

Thank you very much.

Yeah.

Yeah. Thank you, Will. Um yeah, I think networking is a is a big challenge if we want to make fundamental changes. But there are a couple things that immediately came to my my mind actually as you asked the question like uh and more on the like on the CL like one thing that remained unsolved for years now it's not priority at all but like the risk or the SSLE the uh secret slot uh leader election right like basically the DDOS vector that exists and we just hope that nobody will use it and uh uh that's something that I was always surprised like uh just just lives there. And uh I I really like the the pure read or like being able to uh just like have more um uh more uh proving on the EL uh RPC side and also their work on the like Ethan's work on the CL is interesting the centralized checkpoint sync.

It's more about the current uh state of things more than the future and we need to think more about the future I guess. So bunch of this stuff doesn't get priorities but uh this came to my mind immediately like I wish this happened like years ago uh um it's technically feasible and I'm just like you know rambling here so somebody comes up with a question I'm just like buying time so please guys raise your hand come with more questions I hope to I hope to hear from you um [clears throat] yeah I Uh I see we get a couple more people here. Please uh yeah, Charles, go ahead. Sorry, I don't want to monopolize the floor, but I did have another question. Uh I was I was wondering if you think the current um situation around client diversity is like a permanent principle for Ethereum or if it's just a pragmatic way to you know uh guard against um mistakes or problems that can arise and in the future if we might be moving more towards a single client architecture.

Um do you have any thoughts or opinions on that? Uh, I know that this is a I guess the whole spectrum of where people land on that is a a topic that I monitor like pretty closely. Um, it's not one that I have a firm opinion on. If you go back to the the org chart, you know, I think that there's with a lot of things, you know, we just did our um HEGO tier list recently and so we had everyone grade all the EIPs that we want to have in Hagota and you see like very occasionally like uh very divergent ideas within the cluster in terms of you know uh people that are more research-minded might you know think of something one way and people that are more uh you know mainet deliverable delivery like production grade softwareminded are going to see something in a very different way and I I think that that can actually like translate all the way down to client funding and client diversity and so I think that there's people that are like maximally ready to go on formally verified uh client architecture and having a canonical guest program a canonical zk VM and having like Um essentially like uh having fault tolerance which is what we have right now through client diversity. Having fault tolerance through um like verifiably correct uh specifications and code that's compiled down to bin or you know assembly code and so there's no like room for uh you know errors at execution.

And so like you can really take some of these ideas to the very bleeding edge of of technology which people in the cluster are doing right now. And so that's like a very different point of view. And then you have um people that like are very uh mindful of the nuances of these client architectures, the way that uh they interact with one another and suggest that like really this is not something that you can leave to chance and like put you know into a single canonical uh you know uh implementation. And so the only way to uh move forward is with client diversity and you know having multiple implementations so that there's not the risk of uh correl correlating bugs across uh different you know implementations so like language dependent uh versions of an ELCL client team and so always you know wanting to keep minimal viable client diversity you know as the the uh a foundational expectation for Ethereum. And so I think both have a lot of value and I think both have uh benefits and risks that you need to consider and the probably the main risk with client diversity is just the funding sustainability that comes along with it.

And um you know I think that that is something like there might be somewhere in between where you're looking at multiple diverse client implementations but you're marrying that with some of the benefits of formal verification or AI and hey maybe there's like some level of tooling or or something that the EF can help with that reduces the burden on client teams and u therefore makes easier to, you know, provide have sustainable levels of funding for those those teams. And so yeah, it's really just it's a very dynamic landscape as I said before like with AI the way that it's emerging with um the markets and um funding availability as it changes with the new entrance, you know, like who are the the end users of of Ethereum and who has an interest in the long-term su success of Ethereum. These are things that are constantly changing and so try not to like have a fixed opinion on things like that because uh you can very quickly like steel man or straw man any one uh opinion and so you you have to like be willing to be adaptable and uh consider it from all angles. Yeah, I was just thinking about uh the impact to the social layer like if we coalesed into a single client implementation that was formally verified, what would that do for you know crops and and the idea that Ethereum is kind of owned by no one um and everyone um and how would that affect uh just everyone's ability to uh uh create the protocol together?

Yeah. Um these are all great questions. I I think that I am I'm not technical so I I know my limitations in some of these discussions and I think like when you look at when you look at the straw map and you like listen back to the original beam chain talk um like there are crops benefits in oifying and like reducing the complexity as much as possible of the protocol and trying to have something that is human readable or like very easy to understand for anyone that's going to build on it or engage in it. Um and also there's this whole idea of the walk away test. you know like if um you know client diversity is maintained by subsidies from any one entity like that's just sort of false client diversity because if that one entity is no longer no longer able to provide that funding that client diversity goes away.

So you need to be able to like interrogate these uh challenge these ideas from technological points of view, from social dynamics, from funding sustainability. Um and so yeah, like the hard short answer is there's no there's no silver bullet uh to this. It's it's a very I think that that this is like honestly what nerd sniped me and what nerd sniped so many people about Ethereum is that it's not just a technology problem, it's a cultural experiment as the saying goes. Um I think that's Alex Stokes's famous pin tweet. Um because yeah, you you have you have a lot of different incentive structures within the protocol and outside of the protocol that um kind of help inform the or determine the success of it and um people's ability to work on it and contribute to it.

Thanks.

Awesome. Thank you guys. We have a question and comments from Marco. Um I'm curious about your thoughts on the future of our jobs. Is there a future we can hope for or are we going to become unnecessary in the process?

I'm thinking about the engineering growth mostly but also curious about others if there's any difference in replaceability. You have a great experience for people. So I thought you may have some unique views on why people are necessary in the future of dev or not.

I think there's a bright future for engineering. Um I I think that this is a golden era of engineering. My partner, she's an engineer. Um she works at the Ethereum Foundation. And I think that 2026 has been like incredibly uh discombobulating for engineers for a lot of different reasons.

Um there's obviously a lot being thrown at you and I can absolutely empathize. I deal with that level of uncertainty and anxiety um all the time. But I do think that these tools are just so empowering um that it might change the craft of engineering dramatically, but it's not going to eliminate the need for engineering in any way. I think um there might be like uh I you know human code reviewer might be like a new uh emerging uh profession out of engineering uh that comes from this and I think that there's um always going to have to be um there there's a lot of opportunity within uh between the cracks of what LLM s can and can't do. And um humans are always going to be able to bring uh a lot of knowledge and uh wisdom to the process um and also be uh the I suppose the fountain head for new ideas um because you're the ones that are experiencing the the friction and u having the conversations and hearing about the diversity of uh challenges and triangulating on things that aren't uh specific to a pre set, you know, bucket of data um that someone might that a machine might need to train on.

Um yeah,

nice. Thank you, Will. Um yeah, it's actually pretty motivating. I very much agree. I think like these tools are more empowering than anything else.

Um I think it's a very interesting time to be an engineer although although volatile. Um yeah thank you. Okay we still have some time for maybe one.

It does. Yeah,

it does pose another question is um is is Ethereum built for humans or is it built for AIS and does that change your outlook uh on working on it? Um I mean obviously it can be built for both agents and for humans can provide different uh value and different asurances to both user types. Um but it you know like the I mean I I think that Ethereum's becoming more and more important um with the emergence of this new uh user persona um that I think uh what a something like a year ago um 10% of code commits to GitHub were bots and now it's like 70%. % and um same with like web traffic according to um Cloudflare I think this year just a few months ago like hit the 50% inflection point where now more than 50% of all web traffic are bots and um so anyway I mean I think that it it um opens up a lot of new opportunities and a whole new landscape of uh potential ideas of what can be built on Ethereum.

Yeah, I think you will. Um yeah, I think like you know the Ethereum UX being so awful for people, maybe we can actually make it work for AI.

There you go.

Um okay, Christian uh was waiting. Please go ahead.

Yep. Hi Will. Um so I was curious um how you manage from the perspective of the protocol coordination to handle these more discussed I would say like spicy uh EIPs in the process of deciding what's included or not in a fork and motivating and taking like a public stance over those since I saw some EIP recently being heavily discussed like as you mentioned the landscape changes more informations appear um I guess the the stances change and so on so yeah could you give us like a glimpse into that from from the protocol coordination perspective

yeah um I think uh with all a lot of things um in this job trying to figure out a framework and a methodology that allows you to just be consistent and not emotional about things is really important. And so, um, coming up like we just, uh, this is our first time doing it. I'm not saying that it was perfect by any stretch of the imagination. We learned a lot, but really we just came up with a process and um it was sort of ad hoc at the time, but I think thinking back it worked pretty well where we said, "Okay, every team, here's a contribution template. Fill this out.

If you want to grade the EIPs, grade the EIPs. If you want to like um add highle thoughts, add highle thoughts. And so we were able to take all that and from that we were able to create like kind of a priorities doc blog post that was just about the protocol priorities. So all those highle thoughts and then an EIP opinion post and and tier list that was about the graded EIPs and within the graded EIPs, you know, people are adding or taking like S, A, B, I'm sure you guys know how it goes. And so just assigning like a uh a number to that.

So if it was an S, it got a four. If it was an A, it got a three, a two, a one, a zero. And we just averaged these things out and we looked at it and we started to look at, okay, if the average on the left side was quite different, more than two deviations away from the right side, like that's a pretty spicy take where we've got an EIP that is viewed so differently within the EF that like the the right hand side of the org chart rates it as an or as an A and the other side as a DFI for instance or something like that like that's something that we need to get in a room and talk about like how are these two people, you know, sets of people within the same org like viewing this so differently and then also within each side like if there's a lot of divergence and so trying to just take a very like quantifiable approach to it um rather than thinking about who wrote the AIP, what it's doing, like um what have you. that came in later. But really like using um you know kind of first a very just methodical and quantitative approach and then taking that to figure out the nuance and then later on overlaying all right h how does this work with our strategy from like a multi-fork perspective and like bigger picture perspective um and sort of taking a big funnel and and bringing it further and further down with each step of the process.

Yeah, thank you so much. Um, yeah, thanks for uh the question as well. I think it was actually a very nice, very interesting way to wrap it up. Here we are at the full hour. Um, so let me just say once again, thank you so much for joining us today.

Uh, we get got bunch of people who made it. So, thank you so much for joining. Well, uh, thanks for all your great answers for chatting with us today. Uh, it was, yeah, it was a pleasure. It was very inspiring.

I hope that folks learned something new, got motivated here and, um, yeah, I hope you can meet bunch of them at Defcon in in some.

Very cool. I'm looking forward to that. Um, yeah, this will actually, oddly enough, be my first DevCon, Mario. So, uh, I'm really looking forward to it. I'm really looking forward to meeting all the EPFS and uh thanks very much for having me.

Very well. I mean that's that's great. I mean going to be a first uh Defcon for many people here as well. So you can visit us at the day there. Uh awesome.

Yeah. Thank you so much. Uh that's great.

And yeah, have a great rest of your day everyone.

You too. Thanks again. Bye

bye.