EPF6 Office Hours | Potuz

Okay, awesome. So, welcome everyone and welcome Busus. Thank you so much for joining us today.

Thank you for having me.

Yeah, awesome. So, um yeah, welcome everyone to the office hours number eight. Uh today we have another special guest for AMA. So we will have a chat today with potus u core developer of prism consensus client and uh uh already have been uh uh a guest in the AMA uh before but we wanted to have him back especially because recently he's been working on EPBS which is now being uh planned for Glamsterdam. So congrats on that.

It's um uh it's been quite the ride and I wanted you uh guys to meet us to have a chance to actually talk to him and get some interesting opinions out of him. Hope you prepared some interesting questions. But um before uh we open it for the uh for the audience uh I wanted them to get to know you a bit uh understand where you're coming from, what is your background. So if you can share about uh your journey, how did you get into Ethereum? Like what what have you been doing before?

What brought you to the ecosystem?

All right. So um I am a researcher I am a professor mathematician. I have been doing math for the last probably 30 years now probably less 25 years. I've uh during the pandemics I was like many colleagues and many probably of you I was born in a small apartment uh with a very young baby. uh my second daughter was born in 2020 and um I really couldn't do any work at home so I decided to to look into crypto just out of boredom I guess I bought some Bitcoin at the time I bought some Ethereum I heard about Ethereum like moving to proof of stake so I got very excited about that idea I figured since my plan was to buy some crypto and get rich in 10 years and save it and never sell it for 10 years.

I figured locking it into a contract without any withdrawals was a good idea to force me not to sell it. So I uh I bought a validator worth of of Ethereum and I locked it into the contract uh as soon as the beacon chain launched. And then I realized that I had put my money and that most of the developers were not 30 years old that there they had been working on this for not that many years that there were a lot of bugs that the whole withdrawal process wasn't even designed and I decided okay I need to be more involved in this. I started submitting patches to prism. Uh again it was at the time where we were all living in a small apartment.

I couldn't do any actual work in math at all. So I had a lot of extra time and I started submitting paths to patches to prison. Uh the prison guys like started me contacting me and uh even causing me my some troubles with taxes because they started sending me money and um at some point it turned out that they told me, "Well, you're going to continue doing what you're doing. We're going to start paying you and welcome to the team." And I didn't know what to do.

Uh they opened a lot of doors that I didn't know that they were open. They they put me in secret channels that at the time were fantastic. I got a lot of information about bugs. I've learned about some bugs that were preventing the merge from even happening. Some bugs in port choice.

Uh some bugs in the design of the Ethereum protocol itself. and I found those problems and trying to solve those problems and designing around those bugs an extremely fascinating topic. U and that's how I got hooked. I went to Amsterdam as a guest from them at that time and then I decided okay so I'm going to join the team and I'm going to start like doing some more serious work and since then I essentially I haven't left my position. I'm still a professor.

I still have my grad students uh but I haven't done any serious research and I should probably choose one or the other path because now it's unsustainable to do both.

Thank you so much. Um yeah uh amazing. Thank you for sharing all of that and it's uh it's very interesting, very inspiring to see you're the most dedicated homestaker I've met who just started fixing all the underlying protocol and it also makes me realize that it haven't been so long since you've actually joined uh the core core uh in a sense that the defcon Amsterdam was like three years ago. Um and it feels

it was 2021 I think. I'm sorry was

22 was Amsterdam. Yeah. So I joined 2021.

Okay. Yeah. Yeah. Um yeah. So, so um you get very active very fast and I'm wondering what have been some first things that you worked in uh how did you get started with submitting issues or what was the first uh uh first sort of project that you worked on as a part of uh prismatic labs then uh sort of issues.

Well, so uh so what I what I did um was uh I wrote and this was at the time that I was already so the the first few things that I sent to to prison were very trivial patches mostly about login or mostly about the the the the user experience as as a staker. I wanted to have like tools to actually monitor the the node and and and I just added my own custom like things that I wanted to have measured and present didn't didn't expose at the time we didn't really have a beacon API that was stable or or shared among different clients. Uh so we were free to do whatever we wanted on on what the node expo exposed but but soon I realized that the there was a big problem. One of the biggest bottlenecks is on hashing and uh the Bitcoin community has uh a way of of of um of hashing. They they they they have a really good trick to make h the hashing the sha 256 much faster exploiting the fact that we're only hashing 64 bytes instead of like the arbitrary chunks.

and the IBM guys at the same time have a very nice library to do hashing in parallel of things which is exactly what we do with when we're hashing Merkel traits. So what I did is I focused for the first few months in writing my own assembly library for hashing. Uh so when I joined the team in prison uh I spent a good chunk of my time uh hooking I mean validating that this hashing library there in this field there's this saying that you shouldn't roll your own crypto well but now essentially every consensus client uses my hashing library and uh so I spent a good deal of time like validating it fuzzing it proving that it was good and integrating it in consensus clients uh and after that after Amsterdam I focused mostly on fortress. I implemented completely from scratch the force at prism and I am the maintainer you could say of for choice and prison. So most of the for anything that touches for choice typically goes through me.

Thank you so much but awesome. Um yeah um so you've been working on on this area and uh I'm wondering what uh what u brought you to EPBS or how the specifically EPBS uh uh was created where it came from uh how do you see the current design in the future maybe if we can talk about that a bit um um yeah I'm curious about the the the origins and how it differs from what your ideas were before and how it evolved over time. Yeah. So there are different things uh that matter to different people. Um in my case, what matters to me is uh decentralization and trustlessness.

What drove me into into into Bitcoin originally and into blockchain in general is that is the fact that I could with my own computer validate the chain and I didn't need to trust absolutely anyone. when we merged, when we were about to merged, uh Justin Drake a year or two before and uh Vitalic had some posts and into how we could uh scale by by having uh a proposer builder separation and having proposer build separation is it's something that goes beyond just scaling or beyond um the history of the problem is that it is natural that the people that can build the better blocks uh are people that have transactions that have information that most home operators would not have. So it was suspected that uh even even before the merge people were selling were sending bundles with transactions with me and and to extract me to miners and it was suspected this market would generate anyways would be developed anyways after the merge. So correctly so now today every single validator like over 99% of validator do connect with relays and they try to sell their rights to produce a block. Uh so in a rational market it was suspected that most validators uh would try to sell their rights to build a block to someone else that is more specialized that could build a better block.

And the problem was that there was no such relay before the merge. The first relay that got announced was Flashbots and Flashbots said at the time we only had one relay and Flashbot officially publicly said that they were going to be censoring OFAC transactions and this is something that didn't resonate with me and with other with many other developers. At the time the discussion was whether or not we would even support MEB boost and it is it is a tricky discussion um within prison. This was a strong disagreement. U people me and Nishan for example we did not want to support med boost and we didn't really care if no one would use prism.

Some people argued some other teams argued that uh they would support it because they didn't want to risk having uh nodes forking their own clients. Uh and then once you have one or two clients that are going to support it if you are the client that will not support me boost you're going to use all of lose all of your users. So I think this was something that heavily waited on some of my teammates uh and rightly so. People spent years building the client and I was just new and I was advocating to not to drop all of our users. But anyway, so this was something that was in the back of our head.

The fact that uh we required we were enshrining we didn't we needed we were going to use a software that was closed source the relay we was going to be a trusted player in an otherwise trustless blockchain. And this is something that we always wanted some of us always wanted to get rid of. Not get rid of in the sense of forcing that's the that really is not there but get rid of in the sense of like if you want to trust someone is fine but if you want to do a trustless interaction with the builder you have the option and that that's the origin of EPBS is trying to make it trustless trying to make the trusted relay as an intermediary an optional thing and not a force thing on the users. Uh in as much as the running your node is also optional. you can just get your data from etherscan or you can get your data from uh from an RPC provider like infura uh or you can run your own node and get the data from your own node and you don't need to trust your RPC provider.

So it is the same situation that EPBS provides uh if you are an operator uh and you can produce a block but if you want to sell your rights to produce a block you can do this now in a well not now but after EPBS ships in a trustless manner. Now the history of the problem is that no one really cares about this or most people don't really care about this or the tradeoff is not good enough that it doesn't justify for most people uh this removal of the trusted of the trust assumption um doesn't justify inclusion in the in mainet which is is a reasonable argument because every time that you change the protocol you add a lot of risks you cost people a lot of money just the fact that we are going to ship PPVS most probably is going to cost hundreds of thousands or even probably millions of dollars to stake in pools like Lido for example. So you have to wait these things uh and if you're going to make a change in the protocol uh there are pros and there are cons and you really need to wait them and most people are against uh changing just because the removal of the of the trusted relay. Now what happens is that DPVS uh ironically by separating the block from the payload also allows the network to scale and it allows the network to scale optimally. So we know that the best util utilization of the slot would happen with the exact type of pipelining that EPBS provides.

uh by separating the block from the payload. What the node gets is essentially most of the slot to execute the payload. Today you get a block and the consensus block has three things. It has a consensus block that you need to validate. It has inside the list of transactions the execution payload that you need to validate the execution and it also comes with a bunch of blobs that are broadcast separate but they they have to come at the same time a bunch of data that data for rollups in the form of blobs and those blobs need to be checked that they exist.

Uh and all of this happens between second two and second four in the slot. So during those two seconds you're doing three different things. validating consensus, validating execution, validating that the data exists and at four seconds you attach to the block and then the chain advances and during from second four to second 12 the node doesn't do anything. So this is what what uh is actually the bottleneck today into scaling Ethereum uh besides other discussion of the state bloat and we we can get into that if you want but um but but if I wanted to uh run Ethereum at say 100 million gas today we couldn't because we don't have enough time to execute the payload with a 100 mega with a 100 million gas. Uh the the payload could take more than two seconds and we only have two seconds today.

So we couldn't. So what EPBS does is it gives you about 8 to 10 seconds to execute the blog and about 8 to 10 seconds to transfer and broadcast the blob data. So that that sort of scaling is what got most people hooked into and shipping this and that's why it got SFI for Glamstead.

Yeah. Awesome. Very well. Well yeah, congrats again again to that. Um that's um um feels like also the whole governance process is uh uh sort of smoother and I'm and I hope that it sustains this way.

Um it's been um we've had a lot of time uh discussing this and now it's finally happening. So um that's great and guys I hope you have some questions ready. Uh please feel free to raise your hand. I um I wanted to provide some intro and some context so all the people here know what we are talking about, who you are and I hope you have some some cool questions. Yeah, Shane, please go ahead.

Hey, Shane here. I'm helping Mark over at Lighthouse with EPBS. So, uh I'm just curious about like what what aspects of the spec are still a bit uncertain such as like a dual aine PTC for example. Would you say that like the ending payment withdrawal flow is pretty set or is that kind of up in the air? Yeah, just curious as I like implement consensus specs, what uh should I think is like, oh, maybe this a little bit later.

Yeah, so that's that's a fantastic question and and it's you're going to get different answers depending who you ask that question. Um I mean let let me tell you the kind of things that that I I think are agreed upon uh and that no one would tell you this doesn't get in.

Uh so these kind of things are the fact that we want uh the payload and the block to be broadcast separately.

We want the validation of the payload and the block to be completely separate. Uh let's not talk about blobs for a while. Uh so that part of the the validation part of the payload and the blog uh I think is absolutely uh stable.

Yeah, I'm starting with that. Cool.

Sorry,

we're starting with that. So that makes sense.

Yeah, that's so so that that that part how the block the payload is validated and how the block is validated is absolutely stable. I doubt there's any there's not going to be any change on on on that uh on on the on the on the part of the communications the engine between the the the consensus layer and the execution layer I expect no no changes there um now uh the dual PTC thing um so that's that's one of the areas that that needs to be changed that needs to be adjusted But um there's discussion because of this this free option problem that happens that this is not an issue of EBBS. It's an issue of having this dual deadline. So for those of you that do not know about this, what the way EPBS implements this separation is that we require that the payload with the transactions is available at a particular time in the slot. It should be there by say 4 seconds into the slot or whatever time it is into the slot.

Let's call that the payload deadline. And there's another deadline that is when the blob deadline when the blobs should be available. And there's a third deadline which is when the consensus block should be available. Today those three deadlines are together at the same time at 4 seconds. But those deadlines are naturally wanted want to be at different times.

The consensus deadline wants to be as early in the slot as possible because the consensus block is useless. It's only there to tell us this is the head of chain. The execution deadline is subtle because the later you put it, the larger the block that you can broadcast, but also the less time that you get to execute it because now execution comes from the deadline that you that it should be available up to the end of the slot. So that's the the big gain of what's called delayed execution. And uh so that's that's some number that should be within the slot.

Uh since execution takes a long time that number cannot be too late into the slot because you need to execute the the block and in a later uh in a ziki in a zkm world that time is the time that will take for a zk prover to prove the substance. So that time is a is a substantial amount of time. The blob deadline on the other hand wants to be as late as possible because all of the time that you get for that deadline is time that you are broadcasting and using bandwidth which is a resource that we don't have enough. We don't have u infinite bandwidth. So all of the time that you get on the slot to broadcast the blob is useful time for products.

So that deadline needs to be as late as possible and validation is trivial. You just check you have them or not. So it could be in principle really by the very very last end of the slot. Now the problem is that because there is this different deadlines the payload is available say let's put a number 4 seconds into the slot and then you have eight seconds to execute it and the blobs are available 10 seconds into the slot then between 4 seconds and 10 seconds the builder gets an option for free to invalidate its own block. the builder can monitor the markets, realize that he's losing money by including that block and just take it out, mark it as invaluable.

This problem is called the free option problem. And the closer the two deadlines you put, the less of this problem we have. So what we need is to uh to benchmark correctly, get good numbers as to what are the deadlines that we want. There's a inherent trade-off between scaling rollups on every single slot versus having some missing blocks by a builder that would be malicious and would just or rational and would just not would invalidate its own block. So what we want is to have good benchmarks and probably if this problem is just severe enough just have the two deadlines together for example uh in which case the problem disappears.

Um my intuition is that we're going to have some middle ground of what a number that would be considered uh reasonable enough to determine a good block count for rollups. Now uh my intuition is that we're just anyways going to go with this double dual PTC thing and in the worst case scenario just put the two constants to be equal and that's it. and that this that's a way of not having dual bitc by having the dual bitc with the same uh with the same deadlines. So that part I think it's also stable. Now some people want to well we're still getting like different versions of EPBS with or without a relay with enforcing or not enforcing trust payments and so forth.

I need to unlock myself. Sorry. So some people will still push and we will see this push up to like the day that the fork is shipping to remove trustless payments. Uh this is going to be something that people want to get out and it's natural because it touches some people's money. Uh EPBS the way it's designed will naturally shift money from certain parts of the markets to other parts of the market.

the auction will naturally shift into being an open auction into being a sealed a sealed price auction. Uh there there are a lot of people with commercial interests that are very much touched by this. So there certainly going to be interest in removing this just from a purely financial perspective. There's also interest in removing trust as payments uh from a protocol perspective. It is complication.

It is it is complexity that is added into the protocol. uh it is much less complexity than the separation itself but but it is complexity is a nonzero complexity that you add into the protocol for example lido needs to pay to have new contracts to monitor the payment that it will come instead of in a transaction it would come now with a withdrawal uh so it is a trade-off uh and for some people they like the trade-off like myself and some people don't like the trade-off so if you ask me I would say that this is um this is something that is stable. We are going to ship it with trustless payments. H every single CL dev that I know wanted to have it with the trustless payment except Dion which is the only one that officially said no uh uh of the among the CL devs that I know. I think he's the only one that actually officially pushed not to have uh EF research.

there's many of them that don't care or are actively against uh and some people in the community are against. So I think we're going to see a push to remove this and it's unclear to me uh what's going to happen. I as I said one of my main motivation was removal of a trusted player. uh I would be very very sad if this is decided to taken to be taken out especially because it's minimal complexity compared to the actual EI.

I hope I answered more or less your question.

Yeah, pretty much. And I guess uh one point that you said was that like we're for sure separating uh payload from consensus block. Uh quick followup is that uh for the local builder flow though um they're still going to be getting an EL payload from get new payload in the normal execution payload shape. Uh, and I'm curious when they uh are bidding for the block, will they just use execution payload, grab the relevant fields, and put that as the new like execution payload header, then hold on to the other fields from execution payload until it's time to actually create, you know, an envelope,

and they wait till, you know, 40% of access stations or something just like

No, no, you don't need you don't need to count at the stations at all.

I I wouldn't count at the stations at all. Um there's there's no unbundling possible on EPBS. I don't think you need to count at stations. There is an unbundling possible if you are if you if you slash yourself and you're also colluding with the next proposer. So if you have two blocks in a row and you slash yourself and you equivocate on the first block, you can unbundle the the payload.

But uh without this sort of shenanigans of having two blocks in a row uh you as soon as you broadcast your payload after the 4 secondond deadline you cannot be unbundled. So it's useless to try to count at stations. So the the the workflow of how I would implement this how this is implemented in prison is as you said you request a payload from the from the engine the usual way we do when we when you're about to propose a beacon block. uh out of that payload. What you do is you just cache the hash, cache the payload and produce a a header, then you request a header from or bits from the from the builders.

If you choose to use your own, then you just include your own and you sign you sign twice. You sign the header and you sign the block. You broadcast your block and immediately you broadcast your payload because you know you're not equating so you don't care about having that stations. Uh if you're using the builder, well just put the header of the build. So for self-building, there's no need to be doing with with different deadlines or anything.

Just broadcast everything together.

Okay, cool. Yeah, I was so curious about Thanks.

Thank you so much. Great discussion, guys. Uh we have more questions coming in. Jun.

Uh, hi Pus. My name is Jun and I'm working for SSC related things on Prism right now. So, uh, and congrats about the recent news. So, um, I'm I'm also a big fan of EP EPBS. Uh, so it was really amazing to be SFI recently.

So, uh, my question is, uh, is about the the core dev itself. So uh I think shipping a new features at the core devs is important uh also as well as uh maintaining the code base and improving the performance and the stability of the client is also important. So uh what's your priority right now for uh uh for this kind of viewpoints? So, and what's what's your team's priority uh for as a core dev?

So, that's another great question and probably I'm not the right person to answer that question, but uh I mean I can give you a personal perspective but it's definitely not shared nor I I'm speaking for my team. Uh but yes, as you said, um having uh during three different things, shipping new features, uh coding for the features that were already uh scheduled to be shipped. So one is designing the new feature, prototyping the new features, features that might never exist or might never be agreed upon. There's features that were already agreed that we were shipping for the next fork. And there's feature that were already shipped that need to be maintained and need to be optimized and need to be analyzed for bugs.

Now uh there is uh consensus among essentially most core devs and core devs in in general not only client devs but researchers uh community members and devs of at the application layer and so forth. there's huge pressure to deliver forks more often, which means much less time to actually do the last one of the three items that you mentioned. And in fact, in prison, we have known bugs, known bottlenecks that are actually affecting the quality of our code. not only the quality of a public the the actual performance of the node that we just don't have time to work on because we we are prioritizing you might say correctly or incorrectly I don't know but we we have some people that are already overworked working for the fork that was already arranged we have some people like myself working for the fork that wasn't arranged or was sort of like SFI I it the scope of Glneram hasn't been decided yet and people like myself are working on that on that fork and essentially no one has time to work on the bugs that we know exist. Uh so the performance issues that we know exist and I think this is general for most clients.

I think most clients have the situation in which it's very hard to find time to work on things that are maintenance. Uh this eventually would be a problem. It's a problem that it's hard to solve. One solution for example is link type of Ethereum where you just grab start from scratch a new client and that's it. Just replace a team replace code and that's it.

Uh so that's a one way of maintaining code. Just start from scratch and have new code. Uh another way would be to not ship forks uh so often and have time to actually maintain your code. Another way would be to increase the number of people in within teams but that's very hard. Uh we are lucky at prism that we are our mother company not only does allow us to do whatever we want uh for L1 that are not influencing our decisions on L1 but they're also like financing as well.

So we we have a large team but other teams like Nimbus they are very few of them and they they need hands. they need to cope. If we schedule a very large fork, they would definitely not have time to work on other on nothing else. So yes, I I think it's hard to balance these three things that you mentioned and it's also controversial u and there are some push backs. The fact that we are working on prototyping things like EPBS got some researchers mad uh about the fact that we're also delaying fusa.

So, so there there there is contention about uh these three things and how much should we allocate on these three things. Different people believe that uh these three things should be allocated in a different way or that uh certain certain aspects should be done by certain people and some other aspects should done by other people's. pipelining this is very complicated in a decentralized way in a decentralized environment is much simpler if we were just a company if we're just a company in a parameical situation I would just say you work on this you work on that and you work on that and that's it if we had an ethereum project manager we could just immediately allocate resources optimally uh but that's incompatible with having a rough consensus type uh governance system

uh yeah thank you so uh uh If I remember correctly, Prism has some known issues and pro uh progress about improving performance like state diff or uh that you are working uh quite a while and and also I remember about someone saying that every core death has to be allocated for the next next fork work. So I would say M plus two fork uh every every day. So uh I think uh it's it's quite the dilemma for not only for the this client development but also the another uh the worldwide products. Uh yeah so I think yeah it's a dilemma. Yeah thank you for your uh answering my question.

Okay. Well thank you uh Ditri question next.

Yes. Sorry, maybe I'm a little bit out of topic, but I was interested in your background. Uh, what kind of math did you do over the last uh so many years? Um, and during the transition, you said that you had some time because of the corona virus and your family situation, but uh did you have any prior coding experience? I mean how did you feel about it working with developers where like I don't know if you were doing pure math but for example in mathematical physics there was not very much coding apart from Python and also do you miss doing research and do you think that your background was useful to do research on Ethereum like on the classical cells like publishing papers presenting in conferences and all that and I mean based on your last answer I mean could we couldn't we do math to optimize the way that people are allocated in in a decentralized way on how we uh how they spend their time in um in these kind of tasks.

Okay, so these are four different count questions I I counted. I'm not sure if I'll miss some. Let me go through them in a while. Uh so first of all, what type of mathematics I did I do? Uh it's very very pure.

I work on algebra geometry and representations of infinite dimensional algebra. Uh it is something that has connections with the conformal. Most of what I do comes from connections with conformal theory or string theory. Uh yes it was as pure as it could get. Not no not not any applications at all.

Uh coding experience. Uh I am perhaps from a different generation or or or I am what you would call a nerd. I guess I my hobby when I was 12, 13 years old was to disassemble viruses. I had my own collection of floppy discs with like each one of them infected by whatever virus was on the boot sector at the time. And uh yeah, so my my my my dream at that time was to write a good virus that would just uh write himself into the seamos of computers so that not even wiping the desk or the hard drive would would erase them.

Uh so I I would say that I just grew up coding very as a very young person. Um I've Yeah. So since I have memory, I've I've always coded and I liked Incidentally or ironically, I always dislike and I still dislike Golang and I I am I work for the team whose client is in Go. Uh which is something that causes me uh personal trouble. I am a mostly a C++ programmer.

Uh again my my library is in in assembly. So, so that's that's what I feel more more more more I would say at home. Perhaps Rust is something that I might like although I still view this as a language that people do not don't know how to correctly write in C uh use. Anyways, I I digress. Uh yes, I think I've I've I've coded a good chunk of my life.

And like many people that coded for a long time but didn't work in this environment, the big difference between coding and coding professionally is working in groups. It's not coding something efficiently or having a good algorithm that uh that that is done efficiently or in the best possible way. The most important thing about working in groups is have your code being read by others. It should be readable by other people. It should be maintained by other people.

It should not induce other people to to write bugs. Uh and if you're reviewing other codes, you should be able to read their code. You should be able not to add bugs because you didn't understand their code. So, so working in teams I think is a huge difference uh from what I was used for my entire life uh about coding. Uh as you said, Python is a very common language uh both in mathematical physics and in in pure mathematics.

Sage is a huge library that has a lot of collaborators from a lot of people that include myself. Um uh and yes we we we typically do work in Python but I think uh most mathematicians that I know would uh would know how to write for or C uh C++ because those are languages that we used uh from a very young age. Now the other questions you asked uh one was about using math to allocate correctly uh people. The problem is not about the resource allocation in an optimal or nonoptimal way. We we do know that we are not optimal.

This is just a matter of fact by the fact that we need to have five different clients uh and then these five different people, five different set of people have different interests. Each one of us want to have a different feature in the for each one of us have a different um a different view of what Ethereum should be from now in 10 years 10 years from now. So it's not a problem of how do we get uh how do we get there or or even where do we get the problem is we just don't agree and and having the fact that we want to have this decentralization and we want to have governance being decentralized because in an in a blockchain that is not oified the only thing that determines security is it governance system. So, so this is an important concept that people just tend to to not not get. Ethereum is strong and is as strong as it governance system is.

Um, we do not want to be centralized in our governance because even though it would make us much more effective, it would be easy to take. uh it would be a fatal flaw for Ethereum to have a centralized governance system and having an algorithm in particular or even the the concept of an algorithm. I understand that you you're not suggesting that we're just programming and then we're just dividing people to whatever it is but the thing is that having some sort of centralized form of allocating resources into which problem should be solved uh I think it's it's a mistake. It's it's something that we do not want. We want to have disagreements.

We want to have difference of opinions and we want to come to agreement uh even though we might let some people not satisfied with the decisions and this is what happens and this is what has been happening for a while in Ethereum and it would be very sad if we lose this system that we have today. Yeah, thank you. Um, I was also working with Sage. So, I was in algebraic geometry. I was doing intersection theory and the model space.

So, yeah, sorry. Thanks.

Thank you so much. It was uh it was a really nice answer. Uh, Pella has another question. We still have time. Go ahead.

Thanks, Mario. Um, my question was regarding PTC, inclusionless committees, and all these committees we keep adding. Do you think we're adding too many committees and do you think that will cause any problems down the line or if we'll need to um consolidate them or something like that? I'm not sure if there are any issues with that. Uh, it just doesn't seem super elegant.

So, was wondering your thoughts on that.

I I completely agree. There's I don't know how to answer that question. uh and we all get the same feeling uh protocol the the EPVS the the the EIP is not elegant to put it nicely it's horrible it's a horrible monster uh combined with fossil it becomes even worse uh I agree this is not an elegant protocol uh it's also not an easy problem to solve so and the fact that it took us many years to get where we are and we do not know we don't have another solution is makes us like put put these proposals forward is the fact that we know the they are horrible and we still think they're worth the change. Now regarding your actual question which is how do we deal with all of these committees? Uh in fact what we hope for Ethereum in the in the future is uh I don't know if you're familiar for example with this rainbow staking kind of ideas that Barnab and and Rake were posing a couple of years back but the idea would be to have different um different type of node operators.

Today we do have different type of node operators. We have the operator that can actually build their own block and we have operators that can't even build their own block and they just they need to outsource it. Uh we have operators who don't validate. Um but essentially every node operator today needs to be able to at least build an empty block and needs to attest and needs to sign sync committee messages and so forth. We envision a future uh the the large the longtime future of Ethereum would be a future in which we have operators that are running on a synchronous uh on a on a synchronous devices say a cell phone that turns on does something and then it turns off.

We have operators that run on very low powered energy devices. We have operators that run an home computer and so forth. We we want to have a very large number of of of includers. Uh we want to have a pool of includers. We want to have a very large pool of attesters and we don't need such a large pool of posers or even less for builders and so forth.

So my guess is that since these committees that we're adding, they represent different needs to run them. Uh my guess is that we are going to keep them uh and we might even add more as new attributions for validators or attributions for node for full nodes appear. I expect that we're going to have different attribution different set of committees because they will naturally live on different hardware that would that would run them. Uh one good example is inclusion lists. Um if we are in a world in which most operators most node operators don't even have the state and not even have a part of the state then those operators will not be able to submit transactions to be forced included because they don't even know if a transaction could be included.

So, so the the in in a future where where we are in a ZK world, we need to be very careful as to where where do we get this these committees of people that are going to ensure that we have that we are sensor resistant. Um yeah so I'm sorry that I'm answering your question without answering your question but I my suspicion is that once we are in such a world in which different hardware are determining different type of operators that you run uh I expect that these committees will get even more separated and the the protocol would get uglier in that sense even though I mean if you ask this same question to Justin he's going to tell you that it's going to be more beautiful and it's going to be tied up everything in a nice package So there are different opinions about this.

Yeah, it makes a lot of sense. Thanks for the answer.

Okay, thank you. And Lee has a question. Uh yeah, I'm actually was reading your uh post uh Ethereum research about uh the uh faster blog blob propagation in Ethereum. I also actually I I meet the uh Mary at the uh US this year. she gave several talk about the optimal P2P and using random linear network.

Um but I also say you you already mentioned that actually uh because of the coefficient and the field uh to have like efficient small field coefficient is hard. Um uh I'm I'm wondering actually if we use let's say the random linear network coding uh u I mean from my understanding the uh the verific the proof cost and the verification cost because it involves like the multiplication uh uh MSM for the for the proof right so would be pretty high right so but I don't know like uh I don't know the accurate number or the performance. Would that be high? Would that be hard or is that okay? Actually,

uh that's that's a very good question. Uh for I assume that most people here don't don't really know about that work. So, let me just quickly describe what what you're talking about. Uh the idea is to one of the bottlenecks we have today on on Ethereum and that we we kind of are solving in a way for blobs is to propagate blobs is we do eraser coding. To propagate blobs to propagate the data we we do something that is called read solomon encoding.

We we make larger the amount of the total amount of data that needs to be propagated. We artificially enlarge it. Say we have suppose eight blocks we make it 16 or we might make it 32 in the future. Uh but then in such a way that anyone that actually gets eight can recover the whole data. So this allows us to propagate in a much more efficient way the blocks.

Now such a system is not there yet for blocks and this is something that eraser coding for broadcasting or for multiccasting is something that has been used in television system or in uh in radio system has been or the internet in general has been used in the last 40s 50 years uh probably not for the internet but certainly for televisions and um so what I did is I just grabbed all very old literature uh in particular this random linear network coding is work from a professor at MIT Muriel Medah and his her students and actually comes from even earlier uh but has over 15 years and and I I I just wrote down what it would be what are the the parts of that and what are the changes that would been necessary to include this in Ethereum. So the idea would be to spread the block the the con the payload and the block the consensus block chunk it in many many chunks we're talking 10 40 100 it depends on the sort of like topology of the network and then broadcast this chunks separately and each node instead of like rebroadcasting the same chunk that they received they would just mix them randomly and send this random linear combination of these chunks. to new new peers. The idea here is that you never receive the same message twice. So every message that you receive is useful.

So if say there are 100 chunks, as soon as you get a 100 messages, it doesn't matter from whom, from where, it doesn't need to be a particular chunk, you will be able to recover the full node, the full block. Now the question in particular was about um was about the cost of um of exe of computing this computing the there's a matrix that you need to compute there's a matrix that you need to in invert and this matrix has values in uh what is in mathematics known as field. Now for the purposes of security and randomness we only need this field to be very small. So we need say to choose numbers between zero and 255 and that's more than enough from what we need. On the other hand, we need to make sure that the original block was sent by the proposer and that no malicious operator in the middle can inject crap.

That's the big problem when you're dealing P2P network in a decentralized and permissionless uh environment that anyone that hooks into network that says I am a validator can just claim I am the proposer and I'm sending you this block. How do we distinguish this? So today we have a signature. The proposer signs the block and we perform a BLS check a BLS signature check on any message that we get. So if someone makes a block appearing to be the proposer, it will need to forge that signature.

And the point is that what what we need in an ideal world is that sending that message, the cost of repairing and sending that message should be larger than the cost for us to verify the signature. As long as that happens, then it's not profitable to try to flood the network with garbage. So that's why we want to keep the costs as small as possible to verify these chunks. Uh however, verifying a signature per chunk would be horribly bad. Uh if we have a 100 chunks, there's a difference between verifying one signature per block to verifying a hundred of them.

That's going to be very costly. So we have devised a way in which there's still only one signature but there are many commitments uh using some elliptic curve uh and then those commitments need to be verified. Now the actual answer to your question is no. If we're talking about 10 to 40 chunks the verification of the commitments and the arithmetics on this large prime are not a problem. Uh they're very very fast.

uh ped commitments on the restto curve are of the order of microsconds. So I'm sorry I'm locking myself because I forget to remove the screen saver. Uh so so that's not a problem. The problem with the large uh with the large field has to do with the size of the scalar itself. The for an elliptic curve to be safe in the sense that no one can forge beam uh a chunk from the proposer, you need 32 bytes per scaler.

And that means that you're broadcasting 32 bytes per chunk that are extra. And this is garbage that we need to send that is not useful uh part and we need to send on each one of the chunks. If we're talking about 10 to 40 chunks, that's not a problem. And that's why I believe that we are going to use random linear network coding or some version of it or some version of eraser coding. We are going to use in in Ethereum one to broadcast payloads.

This is something that we all agree and I'm happy to work on something that is not contentious. Uh this is not going to have an argument. No one is going to be against we are going to ship some some way of a ratio coding for broadcasting the payload. But the pro the biggest problem on this random linear network coding today for us in the design phase is to use it for blobs. Because when we go to blobs and we have hundreds of blobs and we want to send them all then now the number of coefficients that we need is very large and if we use 32 bytes per coefficient that's just too large and we do not have a way we do not know how to make those coefficients smaller in a safe way.

uh that's an open problem for design that requires someone that knows mathematics and mo it's mostly I would say cryptography and uh yes it's it's still an open problem there there are some ideas floating around but nothing satisfying

yeah thanks uh and uh I don't know if I have time but I can send you the message later yeah thanks

thank you so Um right uh yeah you stopped right there because it's uh the full hour so we are out of time here. Um so thank you so much everybody. Um I wanted to thank you again for taking your time. It was very interesting. Uh I thought we learned a lot.

We get inspired. Um any last words, any last advice you have for the fellows here? Uh something to finish it off with?

Um sorry I'm not good at those but thank you for having me. Yeah. Okay. Thank you so much. Sorry for putting you on the spot there.

Um yeah. Um so thank you so much everyone. It was great and I'll see you on Monday again and uh uh we'll have recording of this coming out soon. Um thanks again.

See you guys.

See you everyone. Bye bye. Bye bye.