Episode 395 - Devnets & Upgrade Coordination with Will & Raúl

Transcript

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. This week, Nico is joined by Will Cochran, research coordinator, and Raul Krypalani, peer-to-peer networking lead, both working at the Ethereum Foundation. This is our fifth episode in our six-part lean Ethereum miniseries. This conversation covers how the postquantum signatures, Snark aggregation, and lean VM stack we discussed in earlier

episodes are actually being integrated into real clients through devets, specs, and cross team coordination. for these special episodes. We also have them in video form over on our YouTube channel. Links are in the show notes in case you want to check it out there. And be sure to subscribe to the channel while you're at it. In this episode, Nico, Will, and Rowul explore the human and networking layers required to make lean Ethereum work. They discuss the challenges of coordinating independent teams, designing new peer-to-peer topology for much larger postquantum signatures, and building the next generation ETH P2P stack. This episode explores how Ethereum upgrades happen in reality through iteration, measurement, and

tight collaboration across different teams and stakeholders. Before we kick off, three quick points. First, ZK Summit is coming back with its 14th edition. Applications to attend are now open. It will be on May 7th in Rome. So, I hope to see you there. Second, ZK Mesh Plus. Our paid subscription tier is rolling. We have released a few bonus clips over there as well as some of our exclusive research reports. If you want to get access, please join the paid tier. Third, if you're looking for other ways to support the show, we have donation accounts visible in the footer of our website. Support definitely goes a long way. So, if you do decide to donate, thank you in advance. That's all for now. Links are in the show notes.

Now, here is Nico's conversation with Will and Raul. Today, I'm here with Will Corkeran, research coordinator at the Ethereum Foundation, and Rahul Krypalani, peer-to-peer networking lead at the Ethereum Foundation. This is episode 5 of our minieries on the Lean Ethereum upgrade. And this one focuses on bringing everything we've seen so far to life, either through the human layer or the networking layer. Um, hello Will. Welcome to the show. >> Thanks for having me. How are you? >> Very good, thanks. And hi Ro.

>> Hi. Thanks for having me as well. >> Yeah, it's great to have you both because I've interacted with you like online through all your coordination efforts or seen some of your work. Uh, so it's great to have you on the show. I'm curious as always to sort of hear like what's your journey into ZK and how did you get to the EF and to your current role? Uh, maybe we can start with you Ro. Yeah. So, I've actually been in Ethereum for I would say eight eight years now. Uh it was my entry point to blockchains. I am a distributed systems engineer. Um and got extremely interested in the networking aspects of of Ethereum. So, uh joined consensus back in the day. Uh helped build a E1 client specifically focusing on the

networking layer uh DHDs and uh protocols and RPX back in the day and things like that. and then uh eventually moved on to to protocol labs uh where I helped build some of the primitives that Ethereum is using today, specifically Libby B2B. I was leading that project um and kind of like made my way into the EF uh last year. So been very connected with the ecosystem, helped shape the the networking layer for the beacon chain and ETH2 back in the day. Um and yeah, so it feels great to kind of like come back and and uh think about the evolution of the networking layer and actually really move it forward uh for the new stage of scaling that Ethereum is poised for. I'll have many questions

about like what the networking layer is and what does that mean. But before we get there, uh Will, I'm curious about you actually because you have very different role to the guests we've had so far in that you don't deal with cryptography but more with people, right? >> Yeah. and probably a a different origin story, I guess. I was an architect for 15 20 years, so designed and built buildings. Um, and yeah, really like it was always a a strong interest in in technology. So, using a lot of automation and simulation to design highrises and things of that nature. And then also on the like very different end of the spectrum within architecture like uh doing construction management and

self you know like on-site managing uh the construction crew and stuff. So like managing these large builds you know really got me uh sort of prone to thinking like ecosystemwide efforts. So you manage and and interact with a lot of people that you're not, you know, employed by the same company, but you're just trying to, you know, move in the same direction, same mission. Um, got to be able to speak a lot of different languages, technical design like layman. Um, and then yeah, my my partner, she was also an architect and became a developer and ended up starting a Bitcoin wallet and that kind of got me into the space. And so I see I was working um on a Bitcoin L2 called STAX. uh ended up starting off as the

grant program manager. So programmatic, you know, program management and uh getting a a broader understanding of, you know, the the technology that's being built on smart contract platforms. And then that moved into like ecosystem program management. So working with the core devs on uh advancing, you know, major upgrades and things that nature. And then I saw Justin's Beam Day talk. And I'd been biting my tongue, my time in terms of like when I was going to reach out to Justin. It was something I really wanted to do for a long time. >> I used that as an opportunity and uh things synced up perfectly.

>> So would you say you're still in construction today? >> Definitely. Yeah. Building building blocks, not not buildings. Uh no, there there's so many transferable skills. Um >> it freaks me out sometimes. >> Yeah. I think it's pretty cool that you brought the two of us together. uh cuz we're very different layers of how uh Ethereum is being built and and lean specifically um I'm will is focused on the social layer and bringing uh all clients together and kind of like coordinating the efforts uh into like a unified pipeline program and so on and I'm literally moving bites on the wire which is how really this network uh multi client network and multi client set of efforts come comes to life uh so

so yeah we're kind of like very distant on the end to side of things but at the same time uh very close together. >> Mhm. So actually this is a great segue into like what I brought to you guys here for which is so far in the series we've talked about right lin theorem is this big upgrade part of this upgrade is postquantum and we've talked a lot in previous episodes about postquantum signatures how to aggregate them with snarks etc. Um but now that we have those things like what do we do with them you know and how does that fit into what is Ethereum? So Ethereum is continuing its scaling journey and in its scaling journey it needs to stay quantum secure postquantum secure right

because this technology is inevitable it's coming so we need to make sure that we plan for it and in that >> uh from that perspective Ethereum I think is really leading the charge in terms of uh um research to verify these primitives to actually uh develop some of these primitives formally verify them and then integrate them um yeah so I think what we do with them is basically put them all together in clients and iterate and iterate and iterate and battle test and stress test uh as we continue scaling the chain as we're already doing but then opening up new magnitudes of scale as we have uh ZKVMs and we have uh recursive snarks and so

on uh bringing them together into clients and like continuing this iteration journey. So can I ask what is a client in this context? Like who who are we talking about? And you mentioned earlier moving bytes on the wire like what wire are we talking about? Like >> you could think of this whole lean Ethereum uh sort of bootstrapping process starting with Justin's beam chain talk and then a lot of community calls and research you know open research calls happening until ECC last year where we had beam day and at beam day there were a lot of like open group discussions where we were finally able to like get all these people that had these uh desperate areas of research and interest. Uh there was also the

practitioners, the the client devs that were there and talk about okay, what's something actionable that we can build like we need a spec, we need something that we're building towards. And so really the the first idea, you know, as like the the critical path, you know, item that we had to, you know, be able to take care of first is signing u these attestations, you know, uh the validity of the block header and being able to like aggregate and and pass those back and forth, you know, within uh the constraints of, you know, three slot finality and 4 second slots. and you know being able to do this as Raul was saying with much larger signatures and so

>> uh that much larger signature and the aggregation uh of those signatures is where the iterative devet comes in. So when you think about the EF, you know, it's like a team of teams. And so, you know, we call these team of teams clusters. And Raul and I both work within the protocol cluster. And so the protocol cluster, you can think of like the core bread and butter is research, spec writing, uh, testing, prototyping, and coordination. And so one thing that's not included in that really is the development of the clients, you know, the actual uh implementation work with the exception of the legendary GU

team. So that's the one client team that's part of the EF. All of the other client teams, whether they're uh consensus clients or EL clients on the current uh beacon chain, you know, or these new lean clients are all outside of the EF. And so within the con context of lean Ethereum, there's actually 10 teams that are building towards this. So uh four >> five brand new teams that are just starting up and then several existing client team consensus client teams that are interested in sort of proto prototyping and and moving along with this research effort. And so we started off with DevNet Zero which was just like hey we we need a spec uh Tomas who you talked with earlier uh he's you know

championing the lean spec and so that's a fully executable >> uh spec and so um starting off with okay we need a a GitHub or and GitHub repos that everyone can contribute these specs to write the specs and then all the client teams need to like have some bare minimum ability to communicate with one another. So proof of concept interoperability was DevNet 0. DevNet 1 was signing these new signatures with the XMS prim primitives, the lean sig signature scheme. And then we needed that was devet one. DevNet 2 was aggregating those um with kind of naive concatenation. And now we're moving into like subnets and being able to like

aggregate these in more sophisticated ways. And then uh Emil who spoke with worked on lean VM that's all gonna come together with recursive aggregation and DevNet 4. >> So all these devets are slowly building towards like a full Ethereum network of like is this consensus or is this execution? Is this both? >> This is just consensus and so there's um there's the ability to you know decide on the fork. So fork choice there's the requirement to like reach finality and then the way that you do that is through signing and aggregating these block signatures. So you need to make sure that like all the network participants are arriving at the same uh conclusions.

And so >> when you change something as fundamental as the signature size um and Justin mentioned in you know one of the earlier calls like faster finality and the postquantum signatures are both like very invasive. And so the idea of trying to target one hard fork where all of this work would be introduced into Ethereum um is sort of the spirit behind these these devets. And so within lean we're always like shooting for an ethos of simplicity and optimality. And so uh all of the tooling, the specs, we're trying to go for minimal lines of code and the spec and like concise design decisions and

and very small iterations and building up complexity >> within the EF and then you give it out to external teams to write their own clients and then they can have their own like philosophy of implementation, right? >> No. So the interop the weekly call that's ecosystemwide. So that's client teams that are outside of the EF, researchers, testers within the EF. Um, and so it's taken a village and so really like all of that uh effort is involving a lot of different organizations, not just the EF. >> Nice. I'm curious now about the the technical aspect of the network.

>> Um, I guess the the first fundamental question is, is it just a matter of like plugging out BLS signatures, plugging in the new one, and life is good? We're done. Uh definitely definitely not. So there's so as well well hinted yeah as well as well hinted there is also faster finality that we're aiming for. There is >> what does that mean? >> Yeah. So that means arriving to economic uh firmness on on the chain um faster than we are today which is uh 12 minutes and there is uh a set of efforts that are already that are ongoing. So one one of them was uh 3SF mini that was uh one of kind of like the designs for faster finality. But there is now a dedicated

fast finality team within the EF that is researching alternative um alternative methods and and designs to arrive to even to have kind of like a fast available chain uh that is able to advance really quickly and then have different models to arrive to to finality at that chain uh on that chain in kind of like um a way that can potentially gracefully degrade if at any point the network is degraded. needed itself. So we're so and I think this is where as we push the boundaries on signature sizes and aggregation of those signatures and kind of like the whole revolving I like to think of it as kind of like a revolving cycle a pipeline that is just like constantly moving to

advance the network. Uh we're really pushing on the boundaries. So we do have uh EIP7870 uh to be precise is the one that defines bandwidth constraints. It's the one that defines uh system requirements for running Ethereum and is the one that governs uh CPU and uh memory requirements but also bandwidth and uh this EIP is uh the bandwidth requirements are moderate because we we want to we want to keep um Ethereum decentralized and universally accessible. And this is kind of like a governing principle for everything that we do, right? So they are deliberately uh moderate. Um and this means that right that that we have those

constraints that were as we push the boundaries of the amount of data that we need to move to validate the chain and to advance the chain on the wire. uh we're budging up against those constraints and of course those constraints can move because over time bandwidth will improve around the world and Neielson's law says that every year there's kind of like a 50% improvement and of course this is this is not uniform around the world and it is it it is not going to continue forever um so of course we can move those but for now we're just staying under those constraints and trying to because I think this is the way that we reach optimality it's we need to like push on the boundary But at the same time like uh force ourselves to be extremely efficient,

>> right? >> And the way that we do that is not is by not like increasing immediately kind of like the bandwidth requirements just saying okay this this is where we are right and the reality is that Ethereum today is underutilizing bandwidth. So it's it has this like very very spiky pattern on the critical path where the network is mostly idle most of the time except for when blocks are being propagated when addestations are being propagated and where aggregates are being propagated. >> This is for the existing network not like >> for the existing network. Exactly. So then one interesting aspect of of lean uh and and PQ signatures is they become they're really heavy. Can you remind us

actually the the size difference? I think we've mentioned it in previous episodes, but it's always nice to have. >> Yeah. Yeah. Yeah. So, a compressed BLS signature on the wire is around 180 bytes and this is 96 bytes from sorry, not the signature, I'm talking about an attestation. So, 180 bytes is an attestation. The signature itself is is 96 uncompressed. Uh, and then you add the data about about the attestation itself. So the so the slot and other other fields and then you add the enveloping on top of that and you compress and you get around 180 bytes and they compress very poorly. So it's like you know the actual uh raw payload would be like a little bit higher than

that but not not so the compression rate is not good and because signatures are >> just to be expected with very dense information. Yeah, >> exactly. Signatures are effectively random, right? Um, and then on the other side, we've got XMSS signatures which are 3 kilobytes. Uh, this is a work working model, even though there are efforts to optimize and to potentially reduce them to 1 kilobyte, which is a which is a moonshot, I'm being told. uh but ideally if we can get under one the MTU size which is the maximum transmission unit which is a really important kind of like concept in in networking because if you send one bite on the wire it's going to you can you

can it's I'm simplifying but you can think about it it's going to cost the same as writing an entire MTU and the MTU is around 1,500 uh it can vary by by path by network path path and so on so ideally if we and get it down to 1.2 kilobytes. It would be a really safe place where it opens up an entire design space for what's possible at the networking layer cuz then we can use datagramgrams uh we can move data in a more stateless way and it becomes really really interesting.

>> So stateless because we were saying one signature one at stationation fills fits into one sort of network unit >> and we don't need to keep track of which units go together. Okay. Like if you spread across multiple units. >> Yeah. Exactly. You're no longer fragmenting and then uh you can have packet loss on the on the network and then if you lose a fragment, you're going to have to wait for a retransmit of that fragment and that adds adds a round trip latency uh which is something we we would try to avoid. But the really interesting um aspect here is I think the pipelining. So um we want this really fast network that is fully utilizing resources that are allocated to it.

>> Right now as I said >> the network is mostly underused except for like these really spiky moments. So what would it look like to actually have a network that is fully utilized and beaming photons on on on on fiber the the whole time and and maximizing uh bandwidth utilization. That looks like having signatures being aggregated at different levels. So, you know, there's topologies that we can talk about. There's hierarchies that that I'm happy to to go into. There's different levels, but you imagine leaf signatures being sent by by validators being aggregated in different points in the network and then further recursively aggregated and higher points and this is flowing constantly. This is happening and new

constantly and it's revolving. So, so new signatures kind of like stronger signatures are or that aggregate more leaf signatures are being constantly emitted at different points in the network and then kind of like aggregated in a cycle. So having uh like a topology like that is kind of what what I think it would be a good decided base for us to shoot for. Let me see if I understand what's happening here. Like let's say we have a thousand signatures. We want to aggregate them. One way to do this is send all thousands to one person and this person can aggregate and tell us this was the aggregate signature. But you're saying there's other ways of doing it, right? Like other topologies and subnets is a way of dividing these people and these signatures. Subnets are

a way of sharding the work that needs to happen. So you then assign validators to uh or nodes to to different subnets and you're parallelizing within those subnets. there's activity happening and then you have a role within that subnet or like with some redundancy which could be the aggregator. This is this is how the the network works today. Um and you would these these uh nodes would be in charge of collecting all the signatures and then escalating a aggregate uh and this could happen over multiple levels.

Um the issue with that approach is that you're introducing latency along the critical path. So then can that is where the pipelining aspect comes in. Can you already start doing work before you have finished the pipel before you finished the end to end? >> So is this the main trick that goes behind you know dealing with these bigger signatures >> or is there more to it? >> It's one one aspect uh I think there are structured topologies that we're looking at. So there was uh research around grid topologies uh that would then create a deterministic um routing approach where you would be having at maximum two hubs between any validator and any other validator that

needs to receive signatures. Anything that nominates a specific node to be a role in the network then needs redundancy as well because you can't just have it for many reasons you can't just have a single node um be responsible for like a subsection of the network because >> you know security concerns and >> I mean if that node goes down then the thing goes down right >> exactly yeah but then uh there's another element here which is you don't want even if you have redundancy at that level which is what we have today. You also don't want um those nodes ideally to reveal who they are because then they become points of attack. If they're

going to be choke if they're if data needs to flow through them, they would potentially be choke points in the network and they would be target for attack. So you don't want to reveal who they are. that gives higher security but at the same time creates inefficiencies because it would be great if you could just send your signatures to to a set of nodes in the network and you know who they are. Um so there's kind of like different different designs that we considering there. So is there a co-design happening between the cryptography sort of the signature and the aggregation teams and the devet team and if there is a code design like will is it essentially down to you to make sure they talk to each other and work correctly.

Well, I I don't know about down I mean I don't know like there's the saying like influence without authority. And so really it's just a matter of like being consistent and showing up and you know letting people sort of know what the expectations are and um and so with that in mind like the the weekly calls are structured to you know sort of allow for all of this activity. And so um you can look at like the call agenda and you can think about it. It helps kind of like you understand how this works. So you know we start off with the client updates and so the clients are always you know consistently working on um you know completing uh becoming spec

complete with the current DevNet. But then there's the previous DevNet which we take from being a local DevNet to being a longunning DevNet. So there might be you know some some efforts involved in that and then there's the if that's devet in devet in minus one and then devet in plus one would be kind of in the research and specification you know phase and so uh there's going to you know looking ahead there's going to be you know further down the agenda after we get through client updates then you get into like the researcher and specification updates and so that's where you get into like the more of the open discussion and you've You got people like Dimmitri and Benedict coming in and providing updates on

cryptographic primitives. You got to talking about the specification and lean multi-ig along with Emil talking about uh lean VM. And so that like helps uh set the stage for the upcoming you know like what's the next set of features you know going to be that we're we're striving for and then also answering any questions that people are having on the implementation phase and then beyond that we also have similar to a lot of Rul's work like okay you need to be able to measure this and like have observability so we've got something called lean metrics uh KACA has been really instrumental in leading that and so this is the idea of having like

client agnostic metrics. And so um you know we have our own uh local DevNet environment that we've built called lean quick start. Uh we run these devets but then you also have to have like key metrics that you're looking at across all those different implementations because 10 teams are writing these and I don't know probably like five or six different languages represented. They have um you know different optimizations. Yeah. And so you want to understand okay like how do like the core signature aggregation or signature generation um signing you know all these uh sort of activities you know what type of performance and latency are you seeing across the

different uh network or implementations and then how are they networking together reaching finality um and staying in sync and so you have to be able to measure that and so uh that's another point where not necessarily network design but like the tools of the trade and like looking at like simulations and and observability you know come into play because as uh Ro mentioned with EIP7870 I think it is the bandwidth and and hardware constraints like all of this you know is not being done in a vacuum but like it there's a everything is resource constrained and like it's all about resource optimization and so >> so actually metrics is a really good

point that I forgot to ask Raul about because it's something I asked um in previous episodes as well like to mine a was asking you know what are the metrics you care about with your VM and how are you doing on those metrics so with them it was you know how many signatures can I aggregate per second with a network what do we look at what do we care about and how are we doing like in the current stage of development >> yeah right so some some metrics are so we have the notion of of throughput which is how many bytes can we move on on the wire? But then the one that we really care about is goodput which is how many actual application useful bytes are capable of being transmitted and uh

on kind of like the critical puff. So is this how many of the signatures can I move around or is that too oversimplifying? >> Assuming that the client can aggregate at an infinite speed, right? And potentially can produce an avalanche of of um of signatures if there's kind of like a multiid data client um or aggregates if it's participating as an aggregator. Then how like assuming it's infinite it's an infinite stream how much is the network being able to transport through the critical path uh and one and kind of like within this a submetric is >> how how many duplicates I have so how much redundancy like what is my efficiency factor because remember this

is a decentralized network and it is not a permission network uh it is unpermissioned unlike other chains which can apply like many optimizations many tricks. If you start if you permission at the networking layer and you know who your validators are, your allowed participants, you know their endpoints. And then of course because these networks secure capital, you need to make sure that you deploy all of the infrastructure to prevent DOS attacks and to prevent all kinds of attacks. if you're going to be revealing what your endpoints are and the fact that there's critical validators or nodes running behind those endpoints. We we don't get to do all all of that, right? We are a decentralized network. You can come in,

you can read the network, you can participate in the network if if your consensus um if you have consensus duties, right? Um so we don't get to do all of that. So how do we um how do we provide the security? We do it uh through different redundancy parts. So it could be physical redundancy in the sense that you have multiple nodes taking um like you you send sorry you send a piece of data to multiple uh to multiple parties. Uh it could be through information redundancy. So this is where racial coding for example comes in. Uh and one of the key primitives that we're looking at is a racial coded broadcast.

Um >> so so yeah I think those are like the key. There's many more. Um of course you have the the topology optimality. So if you're going to be building um a a topology, what is like you can take different measurements of that topology and then over time you can like measure is this the optimal routing like is this arriving to the optimal routing decisions and paths um for data as it moves as it moves around the network. There's many more. >> Is there also a notion of like finality like we said we want signatures to propagate to be aggregated and everyone to agree on what the block was. Is this part of the metrics for the network or is that actually a higher level in the

stack? >> I mean just basically getting the the clients to be able to sync up and and maintain a consistent head of the chain and and reach finality is a a key part of being able to like generate and disseminate these these signatures in a in a timely manner. uh that allows for the rest of those the gears to be able to keep you know working as intended. >> And so what's what goals are we trying to look at and how far are we from them or how close?

>> Well, I think as Ro mentioned, you know, we're within you know the context of the PQ interop and lane link consensus um we're working with this proxy of 3SF mini. So um we know aspirationally that uh Ethereum wants to move towards faster finality um beyond the two epic finality that Ro mentioned to three slot finality and we know that we also want to have uh shorter slots for better UX knowing that that's aspirationally in the direction that we're going but the research isn't you know totally done uh Vitalik actually uh wrote up a very small proof

of concept uh you know version of three three slot finality it's called 3SF mini and so that's what we're using as a proxy right now within um within lean Ethereum and so we're we're using 3SF mini and 4 secondond slots and you know but we also know that the consensus the protocol consensus team is doing a lot of research right now around fast finality and the fast finality endgame and so you know I I guess back to likeord coordination and you know some of the things that like get me excited are you know being able to work across disciplines and plan this next group of uh IRL meetups that we have in can uh

we're calling it fort mode and beast mode so we'll actually have all the cryptographers the client teams Raul talking about ETH P2P we'll have Yan there talking about fast finality and they'll have an opportunity to like really set the stage of okay like what could the client teams be working on. That's uh helps us move the ball forward, you know, for the next 6 months in terms of uh you know being able to you know choreograph all of these signatures and attestations and aggregation in a way that's consistent directionally with where research is going. And then that takes us 6 months out to where we're already planning the next Cambridge get together where we'll uh have all of these researchers back

together. So we try to strategically think about like these six-month separated you know uh meetups that are allow for a lot of serendipity but a lot of research to like you know come out of it and it's also a great forcing function because people want to like present new things and and demonstrate new things at those meetups. >> You mentioned Ro is going to present ETH P2P. Is this what we've been talking about so far or have I missed a mark and there's a whole thing that uh we've missed completely? The devets are actually using lib2p today and they're using kind of like a >> what is lip p2p sorry >> so lippy is the networking stack that powers mainet mainet today um and it uses gossip subub as the propagation uh technique uh and it uses uh a

multi-ransport approach uh that has quick and tcp um but it wasn't purpose built for ethereum so it so lippy is a very useful library Uh it is that aims to kind of like be a general library very composable and modular where you can kind of like stitch together exactly uh the discovery mechanisms and the gossip mechanisms and the transports that a particular application is is going to is going to be using but it wasn't built in with Ethereum in mind and the needs of the Ethereum protocol.

Um so at this point it is it we're looking at EB2P which is the next generation networking stack for Ethereum that has been specifically built and optimized for the network workloads uh that Ethereum puts on the wire. Right? So this is uh kind of like the the substrate that will be kind of like transplanting the devets too as it becomes as it becomes available. >> Is this sort of the topology and subnets we were talking about earlier?

>> So the top yeah so the topologies would be built on EP2P and uh EP2P would provide kind of like constructions to create those topologies. So >> one of the key building blocks that we're looking to to release in um very soon is is the broadcast the broadcast layer. So there is right now devets are using gossip subub which is a store and forward mechanism which means that data is being propagated through through the network and as a node receives it it is going to validate it and then it's going to queue it up for the next nodes uh to kind of like fan it out and continue propagating it on the network.

>> Um >> but it needs to receive the entire message before it can do anything with it. >> Right? So this is one of those inefficiencies that we aim to solve with um with EB2B where basically for larger payloads we divide a message into smaller chunks. We raia code them and then disseminate them on the network through parallel paths so that each node is receiving chunks in parallel and is recon reconstituting the the payload. And if any of these chunks uh goes missing, it is um we have applied a ratio code uh an eraser code to it which means that >> you can recomputee it.

>> Exactly. As soon as you receive enough chunks, you can recomputee it. Um and this is a technique that's that's very useful for um for larger payloads which aggregates are are going to be but it does not help with individual leave signatures. Uh so there's there's a scheduling aspect here and there is kind of like a control plane here. So right now uh we have different uh different objects moving in the Ethereum in the Ethereum network and um we have the EL and we have the CL and they're both like >> execution and consensus layers. >> Exactly. Yeah. Sorry. Um so they're both competing for the same bandwidth. So with ETHB P2P we aim to introduce a control plane.

>> Mhm. where you have like a strict uh like orchestration of what is prioritized at each point in time so that the critical path can uh be like it can can be optimized. >> Uh and there's a lot more there's like improvements at the transport layer where we've been uh using quick as a primary transport layer with zero RT and and and a lot more I can I can go into depth. >> So I guess people should go and see your talk in can right? >> Yeah. Yes. That's a that's a good pointer. Yeah.

>> Great. Well, guys, thank you very much for coming on the show. It was great to talk about how we we are coordinating machines on a network and also how we're coordinating humans building a way to coordinate machines on a network. So, thank you both for coming. It was really fun. >> Thanks for having us. >> Yeah, thanks for having us. I also want to thank the podcast team, Anna, Rachel, Henrik, Tanya, and Hector. To those of you catching us in video, thanks for watching. And to our listeners, thanks for listening.