EPF6 Office Hours | Toni Wahrstäetter

Awesome. We're also Thank you so much for joining again everyone. We have another office hours today and uh uh with um uh with a guest that uh first time uh is joining us for EPF office hours, Tony. I'm not going to try to pronounce the surname. Thank you, Naration.

Uh thank you for being here today. And um yeah uh so another office hours and this time we have uh a researcher or more of applied research person um here um it's been um it's been a while since we had uh uh somebody from this category we have some people from research somebody from development and uh I think Tony's in combine or his team combines these in a um an important way where they prototype the latest research on Ethereum And uh uh yeah I mean you might seen Tony's proposals on ET research uh seen him in uh in the research discussion but also learn from a lot of his visualization of his work on um uh actually uh observing what's happening in on the chain the consensus. So yeah thank you so much again for being here and before I open the questions to to the audience I would like them to get to know you a bit better. if you can tell us more about yourself, about your background, about uh uh where are you coming from, how did you even get to work on Ethereum and what brought you to the research?

Yeah, of course. Um thanks for having me. Great to be here. So um to start with um I started with Bitcoin. So before I got into Ethereum um my passion was on Bitcoin and then in 2017 to 2018 I slowly kind of moved over to Ethereum and it took it took a while.

So I did my studies by the time and then after my studies um I started doing open source work on Ethereum. So I was very active on collecting data um writing data scripts. Um I hosted a lot of data. I hosted some APIs and that kind of stuff. So um those were kind of smaller projects I just did um yeah in parallel to my studies.

And after that um I did a PhD and my PhD was then very much focused on Bitcoin privacy. So this was the time around like 2019 to 2021 a little later and I was very much interested in um all the mixing technologies that existed on Bitcoin like Wasabi and Samurai wallet. Mario's um Mario is already I know you like those mixers a lot too. So yeah, it's it's it's a very interesting technology and I was by the time thinking how this could potentially be applied to Ethereum and CK technology got um quite good by the time um circum was a very um useful tool to to use to write things like to cache and and this was actually then my start into getting way deeper into Ethereum. I was very much coming from the CK side although um I have no um cryptography background or not even anything similar my background is actually in economics and law but yeah I very quickly drifted away from that and focused on Epherum and in 2022 I then joined the EF so first as a part-time employee and then as a full-time employee when the applied research group was formed.

This was a new research team by the time that was meant to bridge kind of the gap between research and and yeah core protocol development and yeah with the latest restructuring. I'm now leading the protocol prototyping team. and very much focused on yeah exactly as Mario already described bringing research um into a more tangible development phase and helping helping people to get ideas implemented prototyped um do simulations figure out um what we can do to improve the protocol so very much on both sides on the research side and on the on the code development side I would say Yeah, I will stop at that part.

Yeah, awesome. Thank you so much, Tony. You know, that's really great and uh yeah, it's amazing to hear that from your words because I mean, yeah, I was I was uh uh agreeing there a lot with the first part like you were interested in the Bitcoin privacy because I uh when I was joining EF, I was actually deciding between working with EF. Uh so I I'm very much familiar with this tech and it's great to hear you're coming from this place. Um but yeah jumping to the present or maybe to the future like um uh what is uh the protocol prototyping or you specifically what are you working on these days which uh initiatives uh what is the current research the current prototyping or something to be excited about?

So I think it's fair to say you can you can say that the protocol prototyping team we look like one or two forks ahead maybe three forks into the future but not like further out and this means right now the focus is of course on both Fusaka and Glamsterdam. So there are big EPS coming up on Glammad um EPBS and block level access lists and many members of the team are involved in in both of them. So we for example Rahul is doing a lot of work on making sure we get the testing right um for Paul Cleavax's list Ji Hun has been helping to make sure we get to a first definite as soon as possible. I have been um yeah contributing to the specs and making sure um yeah cords um yeah work in a coordinated way. So block access is definitely one of the very big topics right now.

And then we got six second slots which is also a proposal that is not like um scheduled for inclusion yet but yeah people seem to like it and there are already like specs done. So this so from this backing side we're basically done with six second slots um on that front and we even have a first definite already. So this is all um work that falls into what uh the prototyping team is doing and apart from that we are also working on ideas that are a little further out in the future. For example, there is a recent idea um called payload chunking which is an idea to just split the blocks the blocks that we have today into smaller chunks to make sure that those chunks can be um executed par in a parallel way. Basically we want to do something while downloading the block um parallelizing between bandwidth and CPU.

And this is this is also one of the very interesting topics um we have been we have been looking into very recently.

Awesome. Yeah. Thank you Tony. Uh yeah a lot of interesting research. I recently uh heard from uh Rahul our former former EP fellow that you guys are bowlers.

Um so I would very much like to push that narrative with the the balls. Yeah. Um anyway yeah thank you so much to that's great. Um yeah, that's great alpha and um like I'm wondering like uh how do you see so being sort of a middle in the engineering and the and the research like how do you see uh the difference there or this um this overlap like where where is it what are challenges like like where is how do you see the difference between the research and the the engineering and how are you able to uh to merge them like uh yeah

yeah it's a good question I think I think it's not it's not like there is a binary um split between the two. So every researcher contributes to um core Ethereum work and vice versa researcher uh every core developer by knowing how the protocol works in depth also contributes to EIPs and stuff. I think it's probably fair to say that most EIPs come from cordfs. Maybe it's like 50/50 between researchers and cordfs. I have no clue actually.

But there are many of those EIPs where you must be a cordf to to come up with those EIPs, right? You must know the protocol how it is actually coded and just looking at the specs might sometimes not be enough. Um not saying that researchers don't look at the core clients, right? I think it's difficult to tell um difficult to categorize people by saying Cordf or researcher because um it's it's way more more nuanced but um in general I think it's more like um the time frame you're thinking in right are you more focused on the next or the second next fork or are you more focused on how do we for example scale the chain in like 5 to 10 years And of course different time horizons then also um lead to yeah um people um working in a different way. Um of course we don't need um a presentation about for example CKVMs every week on all codfs which is very much focused on the more shortterm um time horizon.

Interesting. Thank you so much Dony. Yeah. Um, awesome guys. Um, I think we covered a lot of context about about Tony and his work.

Uh, do you do you guys have any questions? Please feel free to raise your hand and uh, and go ahead and ask if you are curious about something about uh, the current and the future research on the uh, on the Ethereum on the consensus on the uh, so on. Um, feel free to raise your hand. We have also some questions in the backlog from people who put here. Let's start with the light ones.

Uh yeah.

Yeah. Hi. Um actually I want to follow Mario's question because uh your background looks very uh interesting for me because I also just uh finished my uh PhD and uh just give my defense. So I'm wondering like uh uh what's it like what's your uh what's the difference between like uh working as a p like uh doing more research uh versus working for the uh instrument foundation as a research and also code developer uh like the skill wise and like mental wise and all this Yeah, I think that's a that's a very nice question. Thank you.

Um to compare the two, of course, um there are researchers within the Ephim Foundation that there whose day-to-day work looks like um the work that you would expect to see at the university. So I think there while while for example my team is very much somewhere in between research and core development and thus also how we work or how we approach certain topics is different from um the academic work we still um kind of try to contribute somehow to academia even if it's not through research papers then for example through Eve research EE magicians or just by having um an epherum foundation um blog post that documents some topic very well. So my personal experience when I kind of left university and and joined AF was that I just continued doing what I was already doing because I of course um had to um write papers and stuff but in the end I always tried to make my research more tangible and and communicate it to a broader community. So, um, as soon as I then left university and joined AF, this was then basically what I was doing full-time, um, researching topics, um, trying to push them further and communicating that, um, to the community. So, it felt like there were way less restrictions, right?

If you look at E Research, you can publish anything basically there. Of course, um if the admins don't like it, they might delete it, but essentially there is not like a formal restriction. So, I I very much like it. I was always a fan of the open source um movement and stuff. So it felt it felt um great to have um yeah places like Eve research, Eve magicians, all cordfs calls um the testing calls the all the public calls essentially where the progress is happening.

So to me it felt it it still feels like um a very cool um very cool that um so many people contributing to one thing remotely from different time zones and we still managed to to ship like big upgrades to a code base that is not like um simple or um exists anywhere. So I was I was directly drawn into that and for me university was then I was considering um continuing in university but then getting deeper into contributing to Ethereum. Um yeah I it felt like the the better fit.

Yeah thanks. Uh I agree research form and all the are very helpful. I also learned a lot like very uh detailed thing from them about my research. uh but I I also feel there is another like uh challenges because like uh this forms there are quite hiden from the general research or like a paper uh if there if they're there it's quite easy to identify okay this is a part I need to uh read or something like that but for like uh for the discussion on the isome research form you need to like know who is the why you want to follow his discussion And they're usually very long and also the time range could be like years. So and things changed during during like this time.

So you need to have the clue what happened there. So it's kind of like a little bit challenge to for some topics. Uh but in general I feel like all these blogs and like Ethereum blogs and all the code developers read blogs are really really helpful. So yeah, thanks a lot.

Yeah, totally agree. Totally agree with that. Would be it would be nice if if like places like E research get like more visibility or something. It's definitely a very old forum, so it could definitely need a re revamp at some point. But yeah, totally agree with you on that.

Yeah, I can also agree. And uh like especially like with Eat Research and Eat Magicians, it's kind of hard. You know, people would like to merge them. people would like to just like revamp the whole thing but there is no no good way to do it I guess. Um yeah JC has another question.

Um

uh hi uh this is Jimmy. Uh I I wonder uh what is the relationship between uh the PSSE like previously called privacy and scaling exploration they they change the name and and the applied research like it I think there's some overlapping but I like how do you uh differentiate like what works belong to the PSE what works belong to apply research and do you guys uh collaborate or coordinate the works between these two groups

yeah this is a good question there's there's generally um collaboration between the teams but where the prototyping team is more focused on um more the general topics like how can we improve L1 um which falls under the tracks so let me start differently there are three tracks right like scale one scale L2 and improve UX this was like a recent shift and yeah it felt like the community very much agreed agreed on on those three tracks being pursued. And the UX track includes things like getting privacy. And as far as I know, and I'm I'm not a I cannot speak for um the PSE team. Um I'm just following their work as an as a as a yeah as a as a person within the EF and they are very much focused on getting the privacy into into the UX um side. So, making sure that we get the UX stuff right when it comes to privacy.

And I think they just recently had a blog post where they um published some upgrades on what they're focused on and how they want to um contribute on on that front. Whereas getting back to prototyping, um you will see um people on the prototyping team contributing to EIPs, for example, things that need protocol changes, not something that can be done on an on the application layer and um analyzing EIP um simulating them and of course prototyping them. So yeah, I can I can definitely see where you're coming from because it's like privacy scaling and exploration. This is a name that um yeah, summarizes quite a lot. But I would say in the end it's it's very much the focus is very much on privacy um nowadays and this is this is just my personal feeling right maybe if someone from PSE is here they could correct me but um yeah I cannot really speak um um in their name.

Yeah.

Yeah. I mean the team was recently like merged to become a proper EF team and their main focus is privacy as you say like it's not just uh like they gravitate towards it but that's their main thing now. They are now privacy exploration I guess PE uh or the privacy team. So um yeah JC hope that answers the question. Yeah, it's more like they if this is like if this is um 100% true what you said and they are really only focused on privacy and not scaling anymore then you could really nicely separate it into we are more on the prototyping is more on the prototyping scale L1 scale L2 things whereas um private um privacy exploration would then be more on the UX side um although I wouldn't really um I wouldn't really um say this is a a good differentiator there.

Very different teams in the end.

Thank you.

Yeah. Awesome. Um I mean we kind of got to a question I wanted to ask earlier. I want to get give more space for the folks but um this might be a good time uh to ask about privacy. I mean you come in from the privacy background like what do you think about the privacy of Ethereum or where are we heading?

Maybe uh some of these new posts by the PSC privacy team uh there is something that excites you, something to uh prototype maybe.

Yeah, I think I think privacy is one of the very important topics we have to get right. Um in general UX, right? The whole UX topic is just super important and includes many things that might also need protocol changes of course like faster finality and stuff but privacy is one of those things that can be solved on the application layer. So for example wallets um implementing mixers um things like um railway or um yeah there are other solutions um similar to what railway is doing. And then um on the other side there there are mixers and then there is um stealth addresses right.

So we basically have two two um technologies there. Um mixers are of course um more effective because um mixers give you untraceability which is a very strong privacy guarantee whereas stealth addresses only give you um unlinkability. Um, I can very much recommend the the Monero white paper for for um context for more context about those um terms and how to define them. It's a very interesting white paper. It's if you Google cryptonote white paper, you will find it.

It's it's it's kind of old, but if you read it, it still feels like it was written very recently. Very nice. So definitely would say um privacy is super important um and we should get it right on the UX. I don't think we should enshrine something right there proposals like wormhole and enshrining that I'm not sure if if we are ready for that. I just think that's a really big thing and we should be very careful with that.

Yeah. Yeah. Thank you so much, Tony. Um, yeah. Uh, it's been a while since somebody called it Cryptonode or I heard the uh the original original name.

That's uh um that's so cool. I also um uh I've been following some latest monitor stuff. They are actually having hard forks soon. So, we are not the only one shipping hard forks. Uh there are some interesting privacy uh features.

But you're not talking about the the 51% attacks on Monero now.

Oh, no, no, no. just just like research research and uh a new client uh uh release client now um RC for um new version that gives you basically unlimited unlimited set because right now we have the future 16 I'm not going to dive into this call I just wanted to mention that like it's a it's a since you brought it up like uh lot of lot of research in other ecosystems because we have a question uh kind of segueing there also coming from your background and Um some other things to follow. Um uh the question is whether you still follow the research uh over in Bitcoin for instance around BitVM. Um a question from uh from the GitHub.

Yeah. Um unfortunately not as much as I would like to or as I did in the past. Um I'm still trying to keep up with what is happening but um I'm not like um especially with those recent discussions I'm not like trying to stay ahead with um who whose opinion on um yeah the block spam the spamming topic is what and stuff. Um I try to keep up to date with everything that is happening on the on the technical level. So I think I still think it's it's super interesting and I very much like Bitcoin as it is today.

Um, of course it's that's that's also easy to do because there's not that much happening. So saying that I stay like ahead with the technical changes is if you of course if you look just at chain right here the question was specific here about BitVM which is of course doing stuff on on top of Bitcoin. So, I'm not I'm not closely following those um things. I'm definitely aware of them. Um I'm still a user of Bitcoin.

So, I still um use the chain and and and yeah, but I haven't really engaged in in bit um BitVM or something.

Yeah, you got it. Thank you, Tony. Yeah, I think it's always good to just have open mind and understand what's happening elsewhere and be be able to inspire ourselves and like yeah not to worry about the toxic discussions.

Yeah. Yeah. Other chains are doing great stuff and I think it's it's very valuable to to look at other chains too and and check out what what they're doing.

Okay. Um yeah, hopefully back to Ethereum now.

Uh uh yeah yeah yeah back to him. So first of all, I don't know if my message was visible. So now the name of PSC's privacy stewards of Ethereum, that's the new name. And yeah, I have a question that I asked myself and I cannot answer it. So basically, I looked Monero on Wikipedia and it says that it's it has untraceable transactions.

Do we do we want this on Ethereum? Like let's assume that on the technical side it's possible. Do we want to really uh make it impossible to associate a physical like like a human being with the transactions that they do on the network or not?

Yeah, I think that's a that's a good question, right? If we are fine with it, we would probably ship a feature like there is already an ELP for that. If we are not, we might not ship that feature. Right now it feels like um the community is not fine with um enshrining um untraceability into the L1 because untraceability needs mixing, right? There is no way to do untraceability with without mixing.

And of course, you can create mixers that are like you only mix with um trusted entities or with or you exclude entities that um that cannot um yeah bypass certain um manual checks. And I think I think it's it's it's hard to really think about um enshrining it on L1. There are many risk with it. mixers on Ethereum come with um CK um cryptography. Um this is a big question.

Are we fine with enshrining CK um CK into the L1? And then of course there are those questions like okay if we had a mixer that is um natively available on Ethereum one so available to call within the EVM. Would the ETH balance be still be auditable or could someone discovering a buck and somehow cla um yeah withdrawing unlimited E from that contract and we would not even realize right or we would realize very late because you only realize um when so much E was withdrawn that it should should not have been possible. So yeah, it's a it's it's a question everyone should ask um himself in the community like where do we stand on this? It feels like right now the general opinion is um we keep that um for the application layer and don't really tackle it on the on the protocol level.

Thanks. So maybe a more specific question about this was like if we go for it then it would be something like uh accepting like like um illicit activities in the sense that you you can go through Ethereum and then no one could notice and then if we go on the application layer and they allow mixing isn't that uh doesn't that mean that uh you know permissionless the permissionless aspect uh getting is getting weak here because they will have to choose who is like a per like um a trusted entity to mix and who is not. So then you cannot really get uh

uh transactions going through without having an entity saying you are a person to trust or not.

Yeah, I think you can either think about it. I think you have to be very pragmatic here when it comes to privacy. Um, of course we want privacy for the weak kind of, right? So that um everything should be transparent, but we still want privacy for individual for example. And I still I would argue you still have privacy if you are able to exclude certain people.

For example, if I'm running the priv a privacy service, for example, on Wasabi wallet, you have like this entity that runs the privacy service, this entity cannot really observe anything or steal money, but there is one entity that could theoretically censor you by not including you. I think this is still fine because then this entity can selectively decide um who will join the anonymity set and who will not join the set and then there are definitely entities that you don't want to be in an anonymity set with because it's very strongly against morals and and all those things. So I think it's kind of nice to have things like railway. Um so rail gun is the mixer I think or railway and what they do is you deposit and then I think for an hour your deposit is just um sitting there while um anyone or while they are checking that it doesn't come from some um illicit source basically checking some sanction lists or something I don't know actually but I think that's actually fine I think that's a a pragmat atic compromise between no privacy and uh yeah some very weak privacy that doesn't give you anything. So here you you still have a great anonymity set if of course the provider doesn't exclude like too many people.

Thank you.

Thank you so much. Yeah. Um it's a very interesting discussion. The optin privacy or the the default. Um and Bella has a question.

Let's continue with that. We still don't have time. Um

yeah, sure. Uh first, thanks Tony for coming to speak with us today. My question was I just want to get a better idea of what the prototyping looks like. Like I'm working on Fossil right now. I know June made a GU implementation.

Is that normally how it goes forward? Uh, your guys' team makes a GU implementation or is it more just trying to annoy all the other protocol teams to help you guys out or how's that all work out?

Yeah, great question. Um, and it's exactly as you already observed there. So the range is from helping with an EIP, writing ETH research posts and coordinating stuff on E magicians to actually getting into client code bases and implementing stuff ourself. So I would say this is kind of the the range we are um we're moving um in between and yeah so client implementation is definitely something we do um also like spec work or testing. So many many we we touch many parts of the protocol like from the specs to client code to tests to the idea um ideation on if research.

So very much flexible hard to hard to really pin it down but yeah going into code places is definitely something we do.

Thank you Tony. Um before we move on to Lee, I wanted to ask one more question from the uh the GitHub issue uh which is related to this um uh about protocol prototyping. What are uh the skills and knowledge uh that the protocol prototyping team is looking for? Uh more directly what makes a successful proto prototyping researcher? Mhm.

Yeah, I would say the the skills are I I would say um people in our team have a very strong back background when it comes to Epherum in general. So you have to understand how does the protocol work and it's very beneficial to not only focus on the execution layer or the consensus layer but to have a a somehow holistic view on both of them. So I would say this is like probably the most important thing there like really understanding how everything works and this is not not just um understanding it from um from a very high level perspective but I would say um understanding um where to find things in the specs. So it's definitely very hands-on hands-on work. Um there's there's a lot of coding.

We um yeah we we go into client bases do do things ourself or contribute to the specs, contribute to EAPs. So I would say um yeah a technical background is definitely um beneficial there. Apart from that um there's not really a a kind of a model of a candidate for the protocol prototyping team. It's more like a person that is very motivated in getting things done and in a in a short time horizon speaking of one to two years. So we are not like um researching on things for like multiple years.

It's more like looking at the protocol as it is today, identifying some shortcomings and then fixing them.

Well, thank you. Um, yeah, let's continue with

Yes, thanks. Actually uh your question is also like something I also interested and uh uh my question going to be like u uh because you mentioned it would be nice to have a good understanding of the protocol uh I mean before the uh merge we still have the like we still can refer to the yellow paper but I don't think yellow paper is still valid Um, uh, EPF VK is really helpful. I learned a lot from there, but it looks like it's still hard to say I really understand how like, uh, uh, how like very deep how EL works and how they interact with each other. Do you recommend any resource or any way to learn that?

Yeah, this is definitely true. So it's not like um easy to to learn everything and how how things work together and stuff. So like what I just described as Ethereum knowledge, I think there is there is a lot of knowledge that people can have and uh and it's not like a binary thing. So totally agree with that. Regarding resources, I very much um like the specs on both sides.

So there is the Ethereum execution specs repo and the consensus specs repo and to me it's always like um I'm actually look no matter on which side I actually look at the specs I like them on on on both sides and I'm always fascinated by how nice Python code some of my colleagues can can write. So um I really I really when I need to know anything I nowadays go and look at the specs but I remember when I started um and I was not yet familiar with the specs on the CL site there is um Ben Edington's um E2 book um I will post a link into the chat I guess most of you know it anyway but yeah I cannot check I can very much recommend this one. E2 books. So, it's basically a documentation about everything happening on the CL. It's not um full yet.

It's not um complete, but it's a very good explainer about the rational and the design choices taking um that led to the merge. On the E side, um that's more difficult, I guess. Yeah, because you were referring to the yellow paper. Something like this that is updated doesn't really exist as far as I know. Um, from yeah, I would just refer to the execution specs um at that point because there were a lot of changes to the execution specs so to the eels um recently and they are very readable um today.

they were already quite nice in my opinion, but now they are really great and and yeah, I would get I would get familiar with the specs. So if you want to get very uh in into a technical rabbit hole within Ethereum, I I can very much recommend working with the specs um as soon as possible because this is just like understanding how Ethereum actually works or how blockchain works in a very granular way that makes it much easier in the future to then come up with with potential changes knowing what is actually possible and what Yeah, thanks. Uh I Yeah, I agree. Like the presence back actually is quite nice to read in general. Um uh my my feeling is like I still feel struggling with uh like uh the whole architecture like the uh virtualization of the uh viralization of the whole architecture.

So sometimes I feel struggling to understand the uh the like the coordination between different parts.

Yeah, it's the same same for me to be honest. Right. It's it's probably everyone has that has that feeling that it's very complex some from time to time and you cannot be an expert on on every on every small detail there. It's from what what I what my experience was always like okay I need I I was working on one specific small nuanced niche topic and suddenly the topic escalated and touched many other things and you had to learn more and more and in the end when you worked on enough of those niche topics you will you will have covered the whole the whole um yeah the whole protocol. So it's it's just yeah it it needs it needs some time and for me it's it's still a journey I would say.

Uh great thanks. uh I remember one uh another guest in previous like office hour also mentioned that you cannot imagine you can directly know all the stuff is already very huge system now but getting from a niche field and gradually learn it makes things much like reasonable and uh easier. Thanks a lot. Okay, thank you guys. Uh we have uh last quarter of an hour.

Um keep asking questions. Please raise your hands. Um I have one more um uh uh one more question from um uh the GitHub about uh how you pri how you prioritize what you work on. I'm sure you have a lot of ideas that you don't have time to p pursue. So how do you uh choose priorities?

if you're speaking, you're muted. Yeah.

Yeah. Thanks. Um yeah, was just saying never actively thought about it to be honest because um yeah, my my personal work was very much aligned with um those three tracks like scaling L1, scale L2, improve UX. Um same for the work for my team. So there are topics like um buckler laxis lists which falls under the scaling um top um category or the six seconds locked which is um improve UX topic.

um fossil for example which is um great for UX. Um other topic like um in Fusaka we will have um uh a smaller transaction gas limit, right? Um transactions will only be able to consume um 2 to the power of 24 gas and not like the whole block gas limit anymore. Those are all changes that um I've been involved recently. Not like fossil and stuff.

This was more from my team, but the gas limit thing. I've been involved recently and from a pri prioritization thing um standpoint, I was just this was more like me deciding I want to prioritize that work for now and not like um yeah someone telling me I have to do that now. And it's it's very similar for everyone working on my team. So there's not really someone telling us what to work on. So everything is picked up by us or or not.

And from a priorization standpoint, we have to then just be smart when it comes to what are the actual um priorities for the community, for the core defs, for core researchers. Yeah. For everyone, for every stakeholder involved. And luckily we have a very nice um alldef process. Um things are planned well ahead of time.

So we know what is scheduled for glamsterdam when it comes to headliner proposals. We know it already. Um all the um other proposals that um are now in the proposed for inclusion stage. There will be a deadline in a few weeks. So as of that point we can basically start looking into all of those EAPs and evaluate um which one is worth to to ship in Clamster and and which one not.

So yeah this is very much um how how how I think about prioritization there. We're in the end serving um Ethereum and yeah, we want to make sure that our priorities align best with what the community what what all the stakeholders want Ethereum to be.

Amazing. Thanks. That's a that's a great answer. Um folks, do we have uh any more questions for Tony? Please use the opportunity to let me ask all the questions.

anyone? I was just trying. Okay, Shane, go ahead.

Yeah, just curious about how the idea of payload chunking came about in the first place. Uh because you guys were just talking about like work priorities, but I'm just curious about um what is the flow for how to come up with ideas? you kind of alluded to earlier that if you have great understanding of the EL and the CL and their interactions that that kind of opens up the door to be able to come up with these ideas but I'm curious if it's more like you do brainstorming sessions with a few guys or maybe at like Devcon connect those type of conferences uh these type of ideas come about um yeah just just curious the flow there or inspiration

yeah so let me give you two examples for for example for block access list it was really just um a few people in Sicily um with a whiteboard brainstorming and then coming up with ideas how we can introduce some form of parallelization into the EVM and then in the end having a a broad concept of of the design space. I then wrote some blog posts about okay this is the design space this is these are things that we could do. Um as of that point we got a lot of feedback from different stakeholders. Um could narrow the design space a little bit down some first simulations and in the end like like with block level access list we then agreed on on the final design as it is today which is basically block level access list is a state diff plus state locations. Um so a signal for every state location.

For the payload chunking, it was um it was different because we already knew that other chains were doing um similar things like for example on base you have flash blocks which is already very close to the um payload chunking idea. Then Solana has turbine which is also some um non-semantic chunking. I think it's non-semantic actually don't quote me on that. It's definitely some form of chunking. Um what they are doing there calling it turbine doing things what we do with block with blobs um they are doing with execution payloads.

So also very interesting concept. Then there is um Hyperliquid which is this um yeah blockchain alt L1 that launched recently and they explore a concept where you have a big block and a small block within what we call a block today and the small block is supposed to travel faster through the network because it's smaller and they also allow the small block to have access to additional functionality like an order book like an oracle and stuff like this um yeah, Polca dot, Aptos, there are many of those chains that they do interesting stuff when it comes to some new some small parts of their protocol at least, right? And it's very interesting to then think, okay, could this be applied to Ethereum somehow? And for payload chunking um how how I started working about it was basically looking at okay blocks are turning quite big. If we want to 10x the gas limit and the average block size is 100 kilobytes today then the average block size would be 1 megabyte in the future.

and uploading and downloading 1 megabytes to all of your peers as fast as possible isn't is definitely a challenge because we know that bandwidth is is already a quite um constrained resource today. So I was thinking like okay what about changing the streaming process right we today we compress blocks um over the networking layer with snappy compression and you could also use a different compression mechanism that allows actual block streaming on the network or you could do something like Salana is doing with um um taking the bites um that are that what is a block and then um eras encoding it and then sending it over the network in in parallelizable chunks. So there are ideas that sometimes we know a problem like the non-existent um parallelization and then we just meet somewhere and and jam about this idea for a while to yeah explore some solutions and this was the case for block access list as an example and for payload chunking it's an idea that is around for a while it's an idea that is explored on other blockchains It's also a very opinionated um you can you can come up with very opinionated design. So many blockchain do it differently and end up with similar things. Um on Ethereum we are constrained by by different things and have different possibilities.

For example, the fact that we ship block access lists in Amsterdam puts us ahead of all other blockchains that exist today when it comes to parallelization because as far as I know, all the other chains only have optimistic parallelization using things like block STM. So, as soon as you really want to craft a block that is not parallelizable, you will be able to do so. So the only defense against stuff like that is um being a permission blockchain and controlling who who the validators are to ensure that there will never be a validator who creates like a malicious block that is not parallelizable. And with block access on Ethereum, we get perfect parallelization, which means you can execute every transaction in parallel to each other. And this then puts us into a different spot when thinking about okay what is the optimal block structure in the future.

And yeah just to mention those two specific topics.

Thanks.

Awesome. Thank you so much guys. Um thank you so much Tony. We have five minutes left. So uh if there is maybe one more question from the audience let's hear it.

the very last chance to ask Tony somebody and I'm going to take it for myself if you guys don't ask. So please nothing. Okay. So one one thing that I was curious about is I mean it's been the restructuring recently and a lot of things changed but for you personally you are now the leader of the protocol prototyping you have like your own team now. So yeah how does that feel?

How are you handling this new responsibility whether it's different uh what you have learned and yeah how is it like being a team leader? Yeah, to me it it felt very much like um what was previously um the applied research group which was the team I was in before the restructuring now turned into the prototyping team. So my day-to-day work didn't really change except of course that I'm um now managing the team. Um I was very lucky um after the restructuring because of course um if you look at the the the the team my team members right um it is very much we have we have a we have people with a very broad set of skills right so we are involved in repricing stuff we contribute to ideas like um inclusion lists there are people being able to contribute to um the specs and the testing um frameworks and so on. So I think this is actually um yeah the biggest strength of of our team and to me it it it it feels great that we finally um are focusing on exactly that part of of or that kind of work where how do we make sure those iteration cycles between research and core development get um yeah are are executed as fast as possible such that we um yeah such that we in the end ship faster because I think this is super important.

We have to ship faster and we have to take that seriously. we have to um think competitively and on that front I really like that we as the prototyping team we have a lot of freedom in exploring upcoming ideas prototyping them and then yeah going deep into what are the actual um challenges we might expect with certain proposals and what are the actual benefits we can we can expect.

Got it. Thank you so much. Um yeah uh it's also I like just to hear your motivation and how excited you are to just push the Ethereum further. So it's great. I think you're in the right place there.

Awesome. Yeah. Okay. We actually have two minutes to spare. So one more room for a quick question.

Uh I mean to likes to talk a lot. I expected it will take longer but if you guys have one more question uh please uh take the opportunity. Oh, Shane, go ahead.

Yeah, with um EPBS, it pretty significantly changes the CL and as things like uh trustless payments and whatnot. I know you've explored that design space a bit. I'm just curious if now that it's actual actually happening for Amsterdam if uh EF will do like more research on top with things like timing games as well that has come up. Uh just curious if y'all are still thinking about this or whatnot. Yeah, this is this is a good question and it it it's definitely um one of the things I'm thinking most about in the recent months like how should we structure the slot within how should we structure the slot in Ethereum and what do we do with those 12 seconds and how can we parallelize it best and make sure that every resource is like smoothed out over the whole block or over the whole slot.

EPBS is a is an interesting topic because um I was very much against EPBS. Um not like from the beginning but um I never like the complexity and we even had a a a counter proposal to it which was um 7886 delayed execution. Um it's it's a very very broad design space there. So um EPBS is a very opinionated design I would say. I'm not saying it's it's not good.

I'm actually a big fan of EPBS2 because it gives us a lot of scaling. So, it's actually a super powerful um feature. It's just the fact that it's um three things in in one proposal. So, it gives us um a separation of the execution of the execution block and the CL block. Then, it gives us trustless MEF boost payments.

And then it gives us um um yeah the builders that are now um staked entities and we can basically um apply slashings or anything on top of builders when we don't like what they're doing in the future. So it's actually super powerful and I like that that um part of it. But of course on the other hand it's super complex. So if you look at the 7732 specs, that's the EP number about EPBS today, it's not super easy to understand. Um quite the opposite actually.

It's it's quite hard to read. It's quite hard to reason about it. If you look at the fork choice changes, they look kind of scary, but in the end, if you go very deep into that topic, it's a very interesting one because it touches so many different parts of the protocol and things like EPVS. Right now, it's it's scheduled for inclusion in Glammudam. So, it's very likely to happen at this point.

And right now I'm not like looking into its flaws, but more like trying to understand how it's speced and trying to get deeper on that front. I know there are problems with the timing games, for example, that you um um the I mean it's not really called the timing game here. It's the free option problem. I I tend to call it the option problem. Um yeah, it's very interesting um consideration there.

I don't think um right now people are open to change the EPBS design drastically to tackle those open problems and we would just be like okay let's live with them and see how bad they play out um in practice. But yeah, we're still early in the process. So yeah, it's it's it's it's early enough to still to do changes to EPBS if it turns out that the option problem is actually a bigger problem as it might appear right now. I think based on the most recent numbers what I saw it's 0.8% 8% of all slots might be missed.

In case if all validators um connect to one relay or let's assume all relays offer that service, then 0.8% of all slots would be missed um just because people would execute this option thing and would deliberately miss their slot. This is of course uh a very bad outcome in the end if that would be the case but I don't think that theory always plays out um in practice here. Of course um I have a very strong opinion that we should design the protocol in a incentive compatible way that we don't rely on a blog post recommending people what to do and what not to do. So I would feel better if we if we solve that problem through economic incentives instead of um the social layer becoming active.

Got I think also um there's ideas of like moving the at the payload timing committee deadline closer to the station deadline so you have a short gap in when exercise

cost scaling. What do you think about this?

No doubt. No doubt. Yeah. It's Yeah. They're at odds with each other,

right? Yeah.

Yes. So you try to find that happy medium. It's a very difficult gap to find. Yes.

Because between the two deadlines, things like that. Yeah.

Exactly. And in the end, one of the very strong arguments why we went for EPBS instead of delayed execution was because it gives us even better pipelining because you don't need to send um soc because the object the beacon block is super small compared to so the the PTC only checks the um the availability of the payload essentially and it doesn't need to um have the full payload yet. And for delayed execution this was not possible. So you always um a test always needed the execution payload at least download it. And now if we would now say okay let's just move the the deadline f um um further into the slot then this argument comp um that was once um a big reason to go for epbs would then turn invalid and to me it would then still feel like okay then the late execution might actually be the better choice and we should ship 7886 instead of 7732.

too. But yeah, it's a it's a it's a can of forms that I won't open now definitely, but it's a super interesting um discussion and I I I uh I will definitely continue engaging in that one.

Cool. Cool. Thank you for that. [Applause] Mario saying, "Yeah, it says internet died."

Oh,

he say goodbye.

Yeah.

Goodbye.

Thank you, Donnie.

Thank you.

Thank you everyone.

Thank you. Thank you guys. Bye.

Feel free to to um to approach me when you are at Defcon or something. Happy to talk to each of you. Cheers. Bye bye.