Protocol Research Call #1

Transcript

[Music] Um super nice to see everyone here. It's the first protocol research call um co organized by myself and many of our friends at the film foundation and beyond. uh we've been discussing like various shapes of this code for some time like we've always felt yeah there needs to be one of these channels where we can discuss some of the questions that we we do discuss on on discord on telegram in conferences etc like have a bit more of a a shelling point for for this to to happen so we hope that it it serves this this purpose so I want to

start with like a couple of thoughts on what the call is where we intend to to go with this and and then we'll we'll we'll get down to the topics at hand. Um so some of the goals I would say are yeah making this venue which is kind of uh a good place to to present ideas that are maybe not fully formed yet or that yeah seem important but we we're not like extremely convinced yet. um synthesizing the discourse when yeah we post a lot of things a lot of if research a lot of tweets. So trying to paint like a more holistic picture. Uh we want this call to have like a fairly

strong focus on the why rather than the how. So questioning like why we do certain things or why certain proposals are important or why we think they they make sense. Um and yeah the last part that I think would be very nice for for this goal is to essentially accelerate integration of some ideas into the into the road map. So often time it feels like we have many pieces and we spend a lot of time like really sharpening them. Um but it's really about like putting them together in in a in a hole that's that makes sense. Uh that's kind of a tricky part.

and another question that research alone or dev alone uh can um can answer. So very important to to have these conversations together. Um it's also a larger conversation like this call is only 90 minutes. I hope it doesn't feel too long by the end of it. But it's clearly not like we're not going to solve everything uh in 90 minutes uh monthly. We hope that this call is is more like a root of a larger asynchronous discussion um that will happen like through posts as they already do uh papers and any other artifacts that are produced like throughout these conversations. But the

calls can maybe be a bit of like a way to to pose the right questions or to frame them in a in a way that single posts don't address. And we hope that the calls can also be used as a as a reference where we can say oh if you want the lowdown on this topic check out that call and the associated references. I think that would be a very nice u goal. I still think we can make progress like I don't think it's just synthesizing stuff. I think through the conversations that we have here we can probably find some agreement on the places where we converge. often times I find that there's more agreement than I than I expect on on certain topics, especially spicy ones. Um maybe we can

also figure out where there are gaps. So when we present like a certain picture, somebody can come in and say, "Oh, you're completely forgetting about that part." That I think is very important. Um and sometimes we might also like um figure out the path forward or yeah tell ourselves okay this is important to spend our attention thinking about this problem um a bit more and yeah I think that can also come up here. Uh I leave that part to Anca. Yeah. Um I just wanted to briefly jump in because when we talk about a kind of protocol research call, this is kind of intimately tied to the question of where should Ethereum go on the technical side. And um I do think having some sort of systematization when talking about

this is useful. This is here really just a proposal kind of by me in to to try to categorize a little bit where where I see the the current kind research directions going. This is in itself in a way already opinionated. So if you feel like, hey, this is not how I think about the short term or the long-term longerterm priorities or something, no, no worries. This is really just a an attempt at trying to categorize a little bit, but I think um over the next few research calls um it's good to have this as a bit of a backdrop. So so basically the way I see the the the research landscape right now on Ethereum is we have this natural split. Um you see the two rows, consensus layers, execution layer. Um given that we have these this this duplication of clients and of

client teams, usually these these um uh two sides have relatively independent features and feature focuses. Of course, there's often no overlap. So it kind of makes sense to to treat them to look at them somewhat individually. Um and then I distinguished a little bit between like the shorter term priorities. So you can think like what what what are going to be the focus uh the the main focus areas for the next three four hards that that that kind of timeline. and then medium-term meaning meaning for the time after. Um and so the way I see it right now is that on the consensus layer really the main short-term priority um that we have right now is the blob throughput scaling and we we laid the groundwork there with for4 and now with um the upcoming pas we're really

starting to to to rapidly ramp that up. So so I hope that that's going to going to be exciting. That of course doesn't mean again short time it's just like that's the main theme I see there. Um there are other exciting features like fossil for example sensor resistance um that might still very much be in these fogs in the short term but but this is the main theme here that I see and then in the medium term um of course there's um Justin's big effort around the beam chain the way I would conceptualize that is really just that um the the beacon chain on Ethereum was basically like the very first kind of big um like like big attempt at at getting kind of the proof of stake for Ethereum off the ground and we've learned a lot since have a lot more sophisticated understanding. So I

would consider the beam chain basically the opportunity to really get to like the second generation of of ST of of of the entire like proof ofstake mechanism on Ethereum. So there will be a lot of individual features to to look at there. Um and then on the execution layer side um that's actually quite interesting that I think has shifted more in the in the recent past and that of course can mean that it might also shift more again going forward but there seems to be a lot of renewed appetite now to to to look at the execution um throughput on the L1. We have um per purposefully basically left at more or less con at constant level levels ever since the the merge really. Um but there's now now quite a bit of excitement around um uh um yeah making progress there again and

actually um we we'll have announcement there towards the end of the call but but I would like to to have that maybe be the main theme for for the second um um um um protocol research call um in a month. Um so so I'll talk a little bit about that towards the end of this call. Um and then uh the in in the medium term on the execution layer we actually have very exciting features that that have already been kind of part of the the road map for a bit of a longer time. um um that that's that's primarily ZKVM and somewhat related but also separate uh this idea of native roll-ups meaning basically um using the fact that now you have this this kind of execution compression technology also on the L1 to basically give overall a better uh rollup experience. Um and yeah so so

basically my my feeling would be that for many future research calls it might make sense to focus on one of these up areas and then really explore this and then the nice thing is given that we have the monthly that maybe every few months we can also rotate through look back at the category see what has changed these kind of things. So once once we have a bit of a track record here we can hopefully build up a bit of context um but of course not every topic is just neatly fit does not need to fit into a single box. So actually today's topic I think is a really good example the kind of the role of home nodes in the Ethereum network that kind of covers all of these quadrants. So really I think this is is most supposed to be a bit of a guide and actually if you look

at this and you really disagree that's also probably going to be a good kind of basis for for future conversation. Yeah that's all. Yeah thank you. And so yeah, as you said, today the idea is to do a bit of like this very transversal review of uh what home nodes do on the network and and what are they means for so what are the goals that they that they achieve and I think the conversation around home nodes local building is often um centered around their contribution notably for censorship resistance and livveness of the network and this is yeah obviously

very valid because these there are two big contributions of of home nodes. Um but it does have consequences for other goals that the network may want to pursue which are uh things like scaling or things like single serality. And so one of the leading questions that we have today is can we have our cake and eat it too or is it too good to be true and and trying to to highlight uh perhaps some of the trade-offs and some of the different uh points in the design space that we that we can occupy um given let's say new research and and new ideas and also old ideas that are sometimes relevated in a in a in a new light.

And so this call will be sort of in two parts. The first part will be really about uh local building and the question of can we increase network throughput. So the gas per unit of time or the blocks per unit of time uh beyond what can be provided by uh home nodes building their own blocks. Um that's the first part and in the second part we'll uh revisit the path to single certainity with a discussion on two approaches gap validator set and orbit. the the two parts also map roughly to um summary post that I I released on if research before this call and that you can find

on on if magicians and yeah we'll have a couple of people coming in to to present some ideas around this and and we'll also have a bit of open discussion in between for um yeah checking where where we are on this on these topics. So let's let's dive in. Please try to enjoy each presentation equally. All right, first part decoupling throughput from local building and I'll give it off to Tony on his latest post expanding uh meool's perspective giving us a sense of what's happening today in the in the meool.

I let you share your slides Tony. Okay, I think I cannot share ah while you're still sharing. Okay. Yeah. Try again. Yes. Perfect. Can you see it? Yeah. Looks good.

Perfect. Yeah. Hi everyone. My name is Tony. I'm with the applied research group at different foundation and I want to quickly present some stats on the role of local block builders, private orderflow and public mele all findings from my most recent Eve research post. So the question I started at was basically the same that Barnab just introduced. Do we rely on local block builders for liveness and censorship resistance? And I think this is a very important questions that we as a community at some point need to answer.

And in order to guide us towards an answer, I wanted to quickly present some stats around the situation of local block building today. So let's start with private orderflow. So private orderflow is definitely something that has a huge impact on local block building. And as we can see on this chart here, we started last year at like 10% of private orderflow transactions and now we are at 35% of transactions that are not seen in the public mele those defined as private orderflow. And we can see that although it quite significantly increased in summer last year, it then stagnated and we are still at 35% of private order

flow transactions. We can see the same in the green line um in this chart. It's basically the the green line shows you the number of private order flows, the percentage of private autoflow transactions over time. But the more interesting line in this chart is actually the red line because the red line also shows you the gas used. So what we can see here is that although we have around 35% of transactions that are private, they consume around 50% of the whole gas and the same applies to the blue line which is the gas price. So we know private orderflow transactions are not only using more gas but they are also paying more which of course makes the

situation for local block builders even worse in terms of profitability. When we ask the question who gets all that private order flow then the answer is basically the two largest builder. So it's Beaver Build and Titan Builder who get most of the private order flow. And of course private orderflow comes with a with very strong economies of scale because the the more private order flow you get the the more slot auctions you might win the better the guarantees you can give to other companies providing you private order flow. So this is in my opinion a kind of very strong centralizing force on the on the builder front.

So to summarize 35% of transactions are private orderflow transactions. So local builders never see them and thanks to data always we also know that um around 80% of the DEX transactions are private flow. So this tells us that we are already very close towards this theoretical cap of private orderflow transactions because some transactions it will never make sense to submit them as private order flow for example e transfers or something then 50% of the gas used comes from private orderflow and two builders are dominating the space beu and titan and this already has huge impact on

local block building because today local block builders, their blocks are at around 7 million gas. So, um much below the 1559 target of 50 million by now, 18 million. And meth boost builders um expectedly their blocks are right at the 1559 target. So, this kind of tells us local block builders might not be able to get their blocks full. And interestingly, when we look at different sequences, for example, what happens if a local builder builds on top of a local builder's block, then we see local builders are then able to fill the block to up to 14.5 million gas. So, this is fine. But when a local builder

builds on top of a MF boost builder blocks, then we get very small blocks of 7.1 million gas. And vice versa, we see MEF boost builders building on top of local blocks build very big blocks of 23.6 million gas on average. And of course, if you see that um you might directly think of timing games because timing games might be a very reasonable explanation for the fall for for this picture. And I tried to look into that. And what we see here is the seconds in the slot when the block was when the previous block was seen. So for example, um a block seen in second four in the in the previous slot would be on the very right

hand side. And then we see the lines show you the gas used of the average gas used of blocks from the current slot. So for example the green line we can see it moves from 7 million gas on the very left hand side to around 5 million gas on the right hand side which tells us if the meth boost builder published its block very late in the slot. For example the block was seen at second four in the slot then the next block tends to be smaller. Instead of 7 million we might see a 5 million gas block. And this relationship between the timing of the block and how full the next block is is kind of um more or less obvious for all

those lines. So this brings me back to the initial question. Um so local block builders as we just saw already in a very difficult spot. Um especially when it comes to profitability, they have no chance to compete with um professional block builders. and block building is getting more and more sophisticated. We already seen the hardware requirements EIP um where we differentiate between local block builders and standard validators which is um I think it's good that we do so. But this of course opens the question of why do we um initially require to have local block builders and

the two most common answers that you hear is as a fallback for me boost and as a backbone for censorship resistance. But I would argue that we have some solutions especially to the fallback for MEF boost. We have solutions like um yeah having trusted but neutral relays and and simple ways um supporting them like the um the PBS foundation to make it simple to spin up neutral relays and also EPBS and other um separation designs could help here and on the other hand we have inclusion lists where we can basically say um make inclusion lists and not blocks simplifying the work for home stakers so they are they don't need to become um local builders But we might want to have them as

inclusionless builders. And this is maybe a little bit off topic but just um around the topic of censorship resistance. This shows you the inclusion of tornado cash transaction over the last year because one might expect that it were the local builders that included most of the tornado cash transactions. But essentially what we can see here especially on the lower chart that the inclusion rate was larger for me boost builders than for local builders which is something I didn't expect that I expected local builders to be at least um on the same um level where all those meth boost builders are but it also makes sense because some meth boost builders use tornado cash transaction as an competitive competitive edge to out

other builders in slot auction. So, can a batch include a lot of tornado cash transactions to win against the big sensor builder? Yeah. And this brings me to the end. I will just leave that slide up. If there are any questions, I'm happy to answer them. Yeah. Thank you, Tony. If there's any question for Tony, please feel free to raise your hands. Do you want to take a question from the chat? I see both Kev and Toba.

Yeah, let me check the chat very quickly. Or could you read it out? Uh yeah, let me let me take Kev's question. Um what about blob transaction and if blobs were to become more profitable, would how would this change the profitability for local blog builders assuming most or all blobs are sent to the public man pool? I I I don't think this wouldn't change that much because blob transactions essentially are also just um normal type one type two transactions um from the perspective of a of a local builder because what you get is basically the same prior fee as you get for type one type two transactions. So I don't think

blobs will make a huge difference here. And maybe another question from Tomar. uh what's your take on neutral relays versus EPBS and the trade-offs there? Yeah, I think that's a very important question that we at some point as a community need to answer because we can of course rely on trusted relays and have um simple ways to spin up new neutral relays. But in the end, it's also a question of having a buck. For example, if we have a buck in a relay um and it's not part of the core protocol, then we cannot really talk about um very strong liveness

guarantees. And on that point, Mus has a question. How do you feel about relays not verifying blocks before forwarding? We've seen so many bad blocks because of faulty relay software already. So that seems to come back to your point around yeah what we can control as like u core dev community I guess. Yeah exactly exactly at some point if we agree on enshrining relays and then also having core defs be responsible for making sure relays work and the fallback functions work and everything um is treated as the core protocol. I think this would be one solution to yeah to that problem. Of course, um, another one

would be shipping something like EPBS, which is essentially enshrined relays. Yes, George. A home meeting, baby. I will meet you. Um, okay. Yeah. Yeah. I think there's quite a lot of to say about EPBS and and and relays. There'll be like a little bit more discussion. Um I I'll just like give a few thoughts on on basically the the same topic and and maybe we can come

back to to that point. Um let me go back to sharing the slides. Yeah. Okay. Yeah, just wanted to introduce some um visual language to talk about some of these things. But I also come back to a bit later during SSF and also addressing like some questions around what we mean when we say what's a home node, what's a what's a local builder, like what are these um entities that we're talking about and what kind of defines them. The way I like to think about this stuff is we have roles that the protocol want you to assume and you

have on the other side node types. So people mediated by by their hardware uh fulfilling the tasks or or the roles that the that the protocol is is demanding. Um the two roles that we're pretty familiar with is the role of a testing. So coming to consensus coming to finality over what's the canonical chain and the second role is the role of building which is essentially sequencing transactions in blocks and making that uh available to to the rest of the of the network. There's a third role that we're talking about uh more and more which is a little bit related to to the role of building but that you can almost

separate from from building which is the role of including. So the idea that uh parties um decided by the protocol have the ability to to enforce or to or to bind uh the construction of blocks to include certain uh inputs transactions or otherwise. Um so this is not a role that exists formally yet or that has been really separated but uh with a gadget like fossil which is a inclusionist proposal um is a role that we would uh see appear much more clearly on the on the protocol.

Uh so what protocol will give you? Um testing gives you security. So you have like a hardness of the chain. uh building can give you scale because if you build big blocks then you make these big blocks available assuming of course that you you can verify them. Um but including gives you like this idea of of censorship resistance. So if transactions are for some reason being kept out of the transcript or being prevented from getting into blocks. uh you can you have like extra pipes with these includers that that allow you to to get on chain and then you have these operator types.

So people who are fulfilling these services, it's a very crude distinction and it's not a binary one by any mean, but I often talk about home nodes on one side and commercial nodes on the other side or professional nodes. But really the distinction is is not even one of resources because some home operators or solo seekers spend a lot of resources like lovingly upgrading their nodes and making sure that they're performing a very good service. So it's not one of like sophistication or or anything, but it's more that home nodes are a priory untrusted like they they're just pseudonymous addresses on the on the network and commercial nodes come with let's say some kind of credibility that

is signaled either by some legal status as like a company or just like reputation or or a DAO or or some some signal that tells you that yeah you have a trusted quantity on the on the other side um dealing with these with these nodes and then you can also think of a a further dimension to distinguish between like uh who's doing what which is the actual resources of the nodes. So some nodes are minimal and I think that's more what sometimes people have in mind when they talk about home nodes is the idea that yeah it's like these small NUCs or Raspberry Pies that are trying to come to consensus like make these services of at stationation and building

And then you have nodes that are much higher resourced. So not just in hardware, let's say not just like in compute or bandwidth, but also access to order flow as Tony was was mentioning before. That can be a resource that just makes your like a lot more um yeah, a lot more able to to perform certain services such as um building. And so local building is the idea that you have a home node and in fact a minimal one in the case that would be like the the smallest possible node that that's on the on the network as a as a staking node uh that performs this this role of of building and the consideration is whether we can remove the expectation that these types of

nodes so minimal home nodes u perform the building task and instead assign it to to these um higher resource nodes and do that safely and and the questions to that we should ask ourselves is yeah how do we how do we make it safe uh I think one one answer is is definitely for seal so the idea that home nodes are still able to to perform their censorship resistance role uh via inclusion list that constrain the the builder when they when they make these blocks and that gives you that can give you scale but then the second question we have to is the one of of liveness. So what happens when um you call the this

external uh market or set of participants and just nobody answers and then your blocks are not produced anymore. And that can be it can happen just because there's a bug um in the supply chain that makes yeah the block suddenly not appear or it can be much more adversial scenarios where the market on the other side gets extremely concentrated and starts making demand uh to keep the the livveness um going. So very briefly on that I think these are some of the guarantees that we we may want um from this external builder market. The first one is if you make a contract with a builder as a proposer or as like a a staking node um and if the

contract is yeah just uh made canonical the payment should be received. So that's something that for instance you can get through EPBS or through guaranteed payment uh proposals. If you have repeated failures of the external market, you might want to have secret breakers in in some places like either with out of protocol software or even if we have like in in protocol uh solution. Um when you when you make these calls to the market like to figure out like who can build blocks for you, you might want to have like different protocols that allow you to to make these calls. And so for instance, you have today MED boost and uh commit boost. And maybe that diversity is something that we should also be more

intentional about um fostering. Um another thing is you probably want to reward builders that have higher quality of service like that makes them um build more blocks over time. So for instance, making sure that payments go through is one way of of uh rewarding higher quality builders because you're penalizing uh builders that that don't have such a high quality of service. And then you also want to ensure that you you never put yourself or the network at the mercy of of a single entity in the postite detail uh scenarios where we're moving to a ZKVM world and and then we we need provers to to to ensure that the blocks are are valid. Uh yeah, we have

to be very mindful about never putting ourselves in a position where um only a single prover on the network can um can unblock the the chain or make it uh progress. And I think there's ways to set like different sliders in different positions that should at least give us good guarantees or make us feel comfortable with with certain trade-offs. Uh but the larger question is yeah, what's like the the set of things that we need to to really tell ourselves that yeah, this is okay to um to rely on this external building um market and less so on the on the local building um as a as a feature. And that would allow us to to scale uh beyond the

limits of of local building essentially. So yeah, that was a pretty quick uh run through but yeah I would say through thinking about these topics I feel like the two main questions that have appeared to me were first yeah are we ready to decouple throughut from what local builders can achieve? I think that's a question that comes back like fairly often in the discussions we're having especially on the on the blobs and then the second question is how do we how should we think about like ensuring the the lifess of the blocks and we have proposals for doing more in protocol I think DPBS is definitely the the leader here but we also have ways to improve out of protocol options I think

it' be important to to understand yeah what are the what's the sufficient set that that that gives um what we want and yeah I'm sure there's a lot of discussion here so I see already Ben has his hand raised please go for it um blobs aside um if we consider execution realistically since um a large portion of transactions go through private order flow rather than um the public mele which the local builders don't have access to. Even if we dramatically increase the um gas limit, uh I don't think it would

necessarily impact local builders because they wouldn't have access to those transactions. They're going to build smaller blocks anyway. I don't I don't think it's necessarily a problem. Yeah. Yeah. And would you say that there's always the I guess here I would call it worst case where suddenly the local builder could realize like a much higher demand perhaps because suddenly there's a lot of public flow. It's not a worst case because it's actually good for the for the local builder. But would we would we feel sad about the fact that in that case the local builder could just not uh build a block up to the up to the gas limit? like is that is that something that yeah we would we would be

upset about I guess is is one question. I mean they'll they'll do what they can do because I think it goes through sort of multiple iterations of improvement. Um but I don't I don't think it'll necessarily be a problem. I don't think it's too much to worry about. I could be wrong. I saw that the chat was pretty active, but I I didn't get to read it on on guard. Do you see something in there that might be worth um discussing?

Well, um I think Marius had a had a question when you basically talked about the includer role and the the builder role and um Marish basically was wondering does that mean that the builder is then not supposed to include at all anymore? Is that is that not necessarily implied in that name? Like how do you basically segment these these roles? Yeah, that's a good question. And there's actually different uh flavors of architecture I would say. uh we could imagine a world where the builder has no agency over inclusion. So they have to only make their block out of the fossil um outputs. And if you've heard of like

these multic concurrent proposer uh proposals, these were essentially like doing that like you you have a set of people. they each output like a partial block and there's some kind of merging rule that takes all of these partial blocks and make that makes that into like a single thing. Um the fossil design that we landed on is not that uh it's more conditional. It's actually weaker guarantee. So when the includ uh the builder has to include your transaction unless uh the gas of their block is full. So we call that conditional uh inclusion. And the reason why we landed on this design is that it's very me agnostic. You can't really give good guarantees as an includer. And

so that means the includes likely to um to to become very sophisticated about what they include. Like we really want the including thing to just be you see a transaction in your main pool, you should dump it into your into your inclusion list. Uh no no questions asked. I saw as was raising his hand. I don't know if you want to chime in. I was just going to write in the chat instead, but um I was uh about to say if you outsource all transa all transaction inclusion to the includ auction moves there as well uh to a place where it's not optimized for hosting an MEV auction, you know, and um and so you'll end up going back to a lot

of these negative externalities on the network that we were trying to get rid of by having the builders in the first place. And so yeah, you you need, you know, you can uh amend the block through the transactions from the includ, but you want to keep the builder at a fairly high level of agency in my mind. any any last thought on on these questions? And yeah, I I saw ongar commenting in the in the chat saying

that we're not we're not settling these questions today. We're really just trying to get some discussion. Yeah, I guess I can say a couple words in in general. I think this research direction is uh really good. Um, I think that local or like if we if you think from the perspective of Ethereum, it's really about how do you balance throughput and scalability with protecting the censorship resistance and decentralization elements of Ethereum that make it unique and that make that block space differentiated, right?

And um we have been providing this through local building. Um but it's you know it's a way to to kind of get get rid of this constraint on the network. And if you look at what other chains are doing now to scale, it's they do it by unbundling effectively the role of full nodes and into into separate roles that you know can be done by notes of different sizes uh and that hold each other accountable. And I think if you the the beauty is if you move to this framework then you solve censorship resistance through the includers while still being able to scale the network much more uh on the p on the behalf of the bigger nodes that

do like hold the state and do the block building and this kind of stuff and so I for me this it's clear that this you know is a big part of the puzzle for how we can unlock more scalability or Ethereum without hurting any of the guarantees that we have today. Thank you. Great. Then I suggest uh I think there's still some discussion going on, but I suggest to to move to the to the next part. We really packed the goal quite a

bit today, but yeah, I I think it's nice to to be able to paint this this large picture. So yeah, we also wanted to tackle this um this path to to SSF and bundling that a little bit with shorter slot times. uh it's possible to get shorter slot times without going like all the way to SSF, but I think it's pretty clear that to get to significantly shorter slot times, there's a pretty massive restructuration of the of the current consensus mechanism that's that's needed. Uh so I think it makes sense to talk about them in the in the same breath even though they're they're very different u

proposal in a sense. I'll just give a quick intro and then we'll have a few more presentations uh and again some open discussion at the at the end of that. Close that. So the relation between single optionality and and home nodes is that we have essentially different designs that would allow us in theory to achieve uh SSF. But these designs have have different trade-offs and they mean uh different things for for the validator set and its and its composition. Um it seems pretty clear that for any design of SSF we need a relatively small active validator set.

Uh and there's essentially two ways to to to get there. So the first way is to use a rotation. So we have a large valid data set but we're rotating in and out um people uh for for participation. Looks a little bit like what we have today but with a difference that we're not waiting for every committee to finalize. Uh we finalize committee by committee. So it's it's more cumulative. That's one approach. And then the second approach is to just cap the active set and say we have this many validators and there can be a bit of churn uh but the the count um remains uh fixed.

And so yeah it's pretty clear that if you have a rotation you allow yourself to have a larger validator set if not a larger active validator set at at any point in time. And so when you have a larger validator set that means you you pragmatically allow a lot more direct access for uh for home nodes that maybe come in with like not that much tech. So that means in this case the minimum effective balance you need to to enter the validator set can be can be much lower but uh this is uh quite hard and Franchesco will tell us uh more about it um a bit later and so to organize like the discussion here I think what's

important to have to to make or to understand like what's the right trade-off to make is is two things like first understand what's the value of of SSF and the and the shorter slot times uh and and its value with like different configurations. And the second thing is understand the cost of of these different designs and their cost both in in terms of R&D but also I would say in priority. So the longer we wait to ship uh useful features the the more yeah we pay the cost of of people having to wait for them and use less effective things in the in the meantime. And so in the first uh part I invited uh three people to to discuss uh the value of SSF. Each

one will give a few minutes uh pitch on on how they see um this this question. Um and after that I I hope that yeah the three of them can start the discussion for for for some time. So I leave the floor to to Donatr first. Hey. Yeah, sorry I don't have a presentation. It's more of like a short sort of summary of my thoughts on this like why I think this is an important topic. I think fundamentally uh the way I see it um confirming and finalizing thing is things is the most important value that blockchains provide like that's basically what they do

ultimately like we we we now know that we can separate for example execution from data availability and so on. So fundamentally in the end you could say like uh whatever your base layer does is how much data can it confirm in what time and uh um how this in practice why this in practice matters is if you don't do it at an acceptable rate at the base layer then someone else will do it for you like then um the confirmation will move to a system like espresso or something else and um I think we should be very careful with that because it might just mean that if for example we care about value capture um then it's likely that this is one of

the most valuable things you can do. So if we lose it if we simply say oh it's okay if we're not the first confirmation that someone gets we are like just okay if like someone finalizes something after 15 minutes and uh then I think like a lot of value will move away from the Ethereum base layer and I think like that's not a great end result. I think like we should keep as much as possible in there and as quickly as possible like give users certainty. Um thinking about it more in terms of um interrupt uh how quickly the base layer confirms and finalizes is also like the fundamental limit on how quickly you can do um like perfect interop in a way right so you know like we get later

presentations on how you can do it with intense which is cool like I mean that's a great thing and they're very helpful um but again they have their limitations like they require liquidity on both chains. So that means both chains need to like make this investment to get liquidity. Um and they uh don't work for NFTs and like there's all kinds of things that that's limiting to them. And like I think um again they are like a nice additional feature but uh the more confirmation value the base layer can already provide um the more value it fundamentally provides. So I think that's why like I do see uh having quick slot slot times and fast finality um should be a priority for Ethereum.

Yeah, thank you. Very nice speech. Um let me move on to uh Matt Matt Rice from um are you here? Yep, I'm here. Okay, cool. Uh I I'll control your slides. I think it's just a bit easier, but is that okay? Um cool. So um so yeah, I'm I'm Matt. I I work on lacrosse. Um so so I'm sort of the intent guy. Um but but yeah, so I want to talk a little bit about how I see single slot finality, slot times, and interop sort of working together. Um yeah, we can move to the next slide.

So um so for intense um you know as was said previously like I actually don't think that single slot finality is incredibly impactful. It has some impacts but it's not the most um I don't think that users are going to notice a big change if we move to single slot finality for you know at the at the intent layer. Um but I I'll sort of sort of walk through why that is. So like solvers if we did SF right solvers would take less or no reorg risk in filling a user who's bridging out of mainet. Um so higher speed lower costs for users which is good. Um I think these would be you know fairly minor impacts but they they

would be there. Um and then I think the second point is is you know practically not as important today. Uh we don't see it a lot. Um and it's that like L1 reorgs can introd can induce L2 reorgs. So single softenality would like slightly reduce L2 reorg risk which means solvers can do sort of L2 to L2 fills with lower risk you know once again higher speed lower cost um faster block times. I think it just makes the experience of interacting with mainet better and that sort of extends to intents right it just makes makes the intent experience much better. you can do more complicated crosschain actions and have it feel almost synchronous whereas like if you're waiting you know 12 seconds per block it like doesn't feel the same. Um so I think that I'd

summarize this is like the direct impacts to intent interop are mostly felt by people interacting with L1. They're really not going to impact people who are interacting with L2 all that much. Um but I do think that there's sort of indirect impacts and and that's what I get into on the next slide. So like for messaging and large transfers uh I think this is where maybe it gets a little more interesting. I still don't know if single softenality is the is the answer. Um but I think a lot of what we see is the big blocker on uh for interop is the rollup withdrawal delays or rollup withdrawal windows. Um so like the most direct path to trustless cross rollup messaging is to use nested

storage proofs that go through mainet basically. Um and the withdrawal delays are a major bottleneck but for the most part this is like not really dependent on finality being faster on mainet. Um with this definitely impacts settlement. It also impacts uh like how solvers rebalance between chains because obviously the canonical tokens often get minted by the canonical bridges. So you have to sort of do go through this withdrawal window to to do large transfers. Um, and yeah, there's there's large transfers where intents don't work, where a user wants to just send, you know, a million dollars between two chains. Intents are not going to be very good for that. And so, you would need to sort of use sort of canonical message bridges uh to to facilitate that. Um,

and so I actually think these these withdrawal delays are are probably the biggest single uh blocker for uh for interop today and and the biggest problem we're facing in the intent world, but also um outside of intents for helping users do interop between uh between rollups. So um I think it's actually causing because we sort of have this bottleneck on these withdrawal delays, it's causing the ecosystem to move to more towards centralized solutions especially for token minting. So you you'll see a lot of tokens actually start to use centralized operators instead of the native uh like the native bridge. Uh and you know if we if we go down that path a rollup really doesn't inherit in Ethereum security because it's assets are at the end of the day meanted by a centralized

operator. Um, so yeah, I would just say like ultimately like I think there are impacts around the edges um that single soft finality and faster block times can have for for interop, but I actually don't think that they're the biggest priorities um for the interop world right now. Um yeah. Yeah. Thank you so much. It was it was great. Um and yeah, let me turn it over to our last uh pitch from Justin. Hey, so let me share a couple thoughts on SSF and slot durations. In my mind, these are like very different topics. So I'll consider them uh separately. So for

finality, I guess what we want to do is broadly speaking minimize reorgs. Um and my mental model for for reorgs is that we have three different types of reorgs. We have shadow riorgs uh which only involve a few slots and they might happen because you know high latency or you know timing games or or things like that. There's on the other end of the of the spectrum, there's deep reorgs like long range 51% attacks which are you know very scary and then there's the stuff in between um between just a few slots and and multiple epochs. Now what we have today uh which you which is a a two epoch finality gadget you could call

it 2 ef uh two epoch finality um is you know good enough for the really scary long range 51% attacks and one of the things that I want to highlight is that um single cell finality is a bit of of a misnomer and and contrary to popular belief it doesn't really help us solve the really shallow reorgs Um, so that is something that that's kind of fundamental and you part of the reason why we renamed it to 3SF three restart three start finality but really the the question is you know what is the value of minimizing the the the medium reorgs and there's a few notes that I would make here the first one is

that medium reorgs are exceedingly rare like my kind of hot hot guess I guess is that uh mainet has never seen a reorg which 3SF would have prevented like all of the reorgs that we see they're due to high latency timing games or you know momentary asynchrony or or things like that and if we did have 3SF then we would still have these these these reorgs now you know one reason to try and and and have uh mitigation ations against these medium reorgs is when you want to deposit funds to an exchange. Just from

a UX perspective, the exchanges take a lot of time to to process the controls. So the the deposits and here I would argue that uh we have something that kind of works today uh which is this notion of a safe head rule. So as an exchange operator like within a few slots like you should be able uh to uh to process the deposits with with relatively low latency. And so this is more of a of an educational problem than than than a technical one. And then I guess uh another reason to try and mitigate these medium reorgs is um to have resistant proof uh real proof sorry uh preconfirmation. So um as we said

previously um it's possible that the L1 can basically uh cause the L2s to to reorg and and and uh and that's bad. Um but here you can have like a similar mitigation where you you make use of the the the safe head and so overall like my position on on on 3SF is that it's it's not something super urgent that we have to do uh in the next in the next couple years. And then you might ask, okay, what what is in what is the value of 3SF? Well, in my opinion, there are there is still significant value and we still should be doing it, but it's just not high priority. So the value would be one protocol simplicity because we don't need these complicated committees. We

can drastically simplify the fork choice and things like that. It's also very good for matics, right? It's just a good look if your chain has has a fast finality and it's also less cognitive friction for exchanges and pre-confer uh you know work with the finality gadget as opposed to this safe head rule which is more subtle and and hasn't really been adopted in practice. But those are my thoughts on on the finality on the the the slot durations. My take here is that any decentralized sequencer that follows a certain paradigm where you have, you know, this this this

single uh single leader election paradigm will basically um end up in the situation where it has preconfirmations. And the reason is that even if you have like extremely low slot durations, let's say just 1 second um slot durations, that's still too slow for applications, right? Like applications wants 10 millisecond UX or 100 millisecond UX. They don't want one second latency. And so in a world where you do lean on these preconfirmations, you actually have the freedom uh to to have more generous slot slot durations. Um and there's all sorts of advantages to having larger slot

durations. It's more friendly to decentralization. You can have more um active validators, which means that you can lower the the minimum amount of E in order to uh to become a validator. and uh you you don't really suffer uh negative externalities from a UX standpoint because again the pre-confirmations give you that that best-in-class UX which is going to be there anyway. You can kind of think of preconfirmations as being a sunk cost if you've have adopted this this paradigm of of decentralized sequencing with uh a single a single leader at any given slot.

Cool. Yeah. Thank you so much, Justin. Um, yeah. Yeah. So I was wondering if among the the three of you like you've you've given like nicely different perspective on the value of SSF or let's say shorter slot times like is there something that one of the other panelists said that strikes you as oh this is very different from from my own thinking or some a place where yeah there's an irreconcilable difference perhaps?

I mean from my perspective I I agreed with a lot of what Dankrat and Matt said, but I guess you know maybe in their mental model they're not considering the pre-confirmations as even part of the design space. And I think if you if if you are willing to accept this this this larger design space then uh you can uh you can have really nice nice designs and and and nice trade-offs. Now pre-confirmations are extremely like recent ideas and only now are you starting to see systems like you know base and uni chain and and all sorts of other systems you know uh start signaling that they they want to support uh preconfirmations

uh and so really the proof is in the pudding for 2025 to show that yes in practice these preconfirmations can be robust um and I think hopefully you know in 2026 and beyond and we can we can start taking preconfirmations for granted and kind of enter this preconcentric road map if you will. I mean I feel like where I would I would kind of disagree is on the um I'm again worried about the value capture side. So I think preconfirmations on the base layer look a lot like just faster slots.

So maybe if we want that then we should move to very fast slots and a little bit slower finality. if we give them if we don't have them on the base layer but have some other construction then yeah I'm worried we're giving too much away like we're giving potentially the most valuable piece of the stack away and uh that would make me quite worried like to make that the official position.

Hey, we want someone else to do this thing for us. My definition of a slot is basically the amount of time it takes for one round of attestations. And like my assumption is that we're dealing with a fairly large number of of testers and you know in a decentralized setting with home internet connections and so you know the realistic number that I have in mind for a slot duration is is roughly 1 second. On the other hand, with preconfirmations, the notion of time is a tick. Uh, so that's the the minimum amount of time that it takes for one single entity, the the proposer or the sequencer to make a decision on giving

out these promises to to to users. And and the tech duration can be, you know, as low as as 10 milliseconds, which is, you know, two orders of magnitude faster than what the fastest we can achieve, you know, with uh with slots in a decentralized setting, right? I guess like I would still contend that if this is what we want then uh we should bake it into the base layer somehow. We should add a way of uh confirming these as intermediate blocks by the same proposer

um with at least some obviously not perfect checks by testers like we don't necessarily need roundtrip latency on those. We can have we can have we can do that on on higher resolution than roundrip latency if they mean anything at all. One of the things that we've kind of observed is that in order to have robust kind of incentive compatible preconfirmations, the amount of economic security needs to be fairly small because we're dealing with very small durations of you know one one slot and like ballpark number is about one E of economic security. And so that's the

kind of collateral that doesn't require attesters. It's something that a single sophisticated proposer in the context of IPS can single-handedly provide um and and provide you know robust and incentive compatible reconirmations. Thanks. Yeah, maybe I think there's a lot to say on on on preconfirmations. Um I I wanted to ask uh Matt at the end of your talk you you mentioned that SSF shouldn't be the priority for Interup. Um and I've seen a question also in the chat in your sense like then what should be the the

priority things to to ship at the L1 or otherwise that that would help have better interop like throughout Ethereum. Yeah, I think um I put in the chat, but I think it's like I know uh there's work at the EF already around standardization. I think the intent the whole intent world needs more standardization. Um so that's a big one. Um I think that I think there needs to be a lot better wallet support for crosschain actions. Things like uh yeah, just like better support at the wallet layer for this. And then um so you can so users can sort of combine uh like an action they want to do on a DAP with sort of a bridge to get the funds there.

Um and then like I think like faster slash better trustless messaging. Um I think there's a lot of trust trust dead messaging systems that are sort of taking the place of what trust what trustless messaging could do if it were better. And I'm concerned to see like a lot of the space just sort of leaning into uh like what I'd call like multi-IG messaging um because we can't do rollup to roll up messaging quickly and trustlessly. Um there's just not a good way to do it with with ZK proofs. There's not a good way to do it with with through mainet withdrawals. So that's that's painful. And then like I said uh during my my uh my little talk there, uh I think like decreasing the amount of time it takes to actually pull

funds out of the rollups. um back to mainet would be a huge deal. It would it would make interop way better and way higher throughput. So those are the big priorities from my from my perspective. Yeah. Thank you. And do reconfirmations maybe address some of it? Like can we think of them as enhancing this faster or more trustless messaging? Uh I mean pre-confirmations on I'm not sure how they would how they would get you there. Um because like we're talking about like I mean the big barriers right now I think we're talking about like 7day delays on withdrawals right and like I don't know how pre-confirmations

on mainet would would really do much there. I think once these times once you have these withdrawal delays get really really short like finality on mainet and how fast you can actually move stuff through mainet actually starts to matter a lot more and so I could imagine down the road that being a having practical implications on interop but but maybe I just don't see it today. Um I don't know if if Justin has a different perspective and thinks there is a way this has an impact today but but I just don't see it. I mean I have a totally different worldview as to you know what is a successful you know ecosystem of L2s that has strong network effects. Um and basically my my worldview is synchronous

composability versus async which is I guess your worldview like the the thing that makes me like most bullish on synchronous composability is just the empirical observation that any blockchain ecosystem that has tries to embrace asynchrony you know whether it's it's Cosmos or Polka Dot or Near or Ton or the internet computer they've all basically haven't had this product market fit with the the devs. because the devx is just so uh so bad. Um and in order to achieve synchrony, you need like a few magical things. The first one is the real time proving. We're getting that, you know, in a matter of of of months. But then the really hard thing

is having all of the O2s converge on this shared sequencer. In order to have a shared sequencer, you need a credibly neutral shed sequencer. And unfortunately, we have only one of them, which is if L1 itself. Uh and the way that pre-confirmations come in is that it makes the only credibly neutral or shared sequencer actually, you know, good good from a UX perspective because uh it reduces latencies. And so for me, you know, pre-confirmations are like absolutely key to achieve this good interoperability interrupt. But I agree with you that if if what you're aiming for is just this weaker notion of as asynchronous compuh composibility then

then you know you you you don't need these kinds of of R1 preconfirmations. Yeah. I mean I think just to say really quick I think our views are actually pretty compatible here. Um I my view is that like if those if those magical things happen I think synchronous composability is like definitely better than asynchronous composability. I think it's a question of whether whether we think those things are are achievable um and over what time period. Um, and like one barrier today is like I think it's going to take a while to build out I believe like even if we did have uh like if we were able to have real-time proving you'd have to build that out for every single L2 you know L2 chain right and so you'd have to you'd have to go

and like actually write that you know somebody have to go out and write all of those those circuits or or all the or all those uh you know proofs and that uh from what I've seen that that's going to take a considerable amount of work and a consider amount of time. Um but yeah, I think that's a that's a completely compatible view. Thank you. Thank you both. Um yeah, I I suggest it was a very interesting conversation. Um I suggest to to move on to the to the next part which is uh more on the on the cost of SSF having discussed now the the value um and I leave it to to Franchesco to to give the the presentation here.

Um, should do you move the slides or or do you want to stop sharing? Up to you. I can stop sharing. Okay. Uh, yeah. So going back a bit to something that Barnab was talking about before this last segment um we have these two uh main mechanisms for for leader selection that that are being considered that I discussed in this post. One is the easier one the cap validator set um where we just yeah really have a fixed number of validators that we can allow and somehow we we ensure that and there's like different mechanism that you would do this but it

doesn't super matter for the purpose of this. Um and then there's orbit or some kind of more committee based thing. It doesn't have to be uh necessarily orbit but focusing on orbit. Uh the idea is there is that you would rotate validators uh proportionally to their balance and uh so yeah if you have more balance you be in more often and you actually only cap the active set. So you still get capping but uh not for the whole validator set just for the people that are actually at a given moment in time voting. And uh yeah the main complexity just standalone when you're just thinking about the leader selection mechanism um is not in the leader selection mechanism itself like we have committees already we kind of know generally how to to deal

with them in terms of just selecting them um it's it's mostly just in the incentives for the cup validator set part it's it's still not um it's simpler it's not nec there's questions there but they mostly revolve around basically large stakers splitting their stake to push out smaller validators. Um it's at least something that I think it's a bit better understood. Uh whereas for orbit there's all these questions around consolidation incentives. Um which I think where like there's I mean there's been a lot of research by by Anders which I think is on the call. uh but yeah I think uh this is something that's much more uh recent as even like part of the design space and it is actually really uh necessary in order for for

this design to make sense uh not only for it to be useful but also to to be secure um and then there's um yeah so the the that's the leader selection part then there's the consensus protocol part uh which yeah we've been saying SSF for the most part I'll focus on 3SF like that Justin already mentioned Uh so three slot finality where basically the idea is we kind of uh pipeline everything over uh slots. So we don't try to do all of the uh rounds of voting that we need to finalize in a single slot. But uh we only confirm a block in the in the first slot. And this is something related to the u discussion that was in the chat about the confirmation rule. It's not the same confirmation rule that was

mentioned there, but it's still this idea of having a strong safety guarantee that isn't finality at this point. Um, so it's not like slashable or anything like that. Um, and then yeah, justifying and finalizing over the course of three slots. And uh, each slot kind of looks the same as today's slots. You still have proposals, you still have a head vote and a FG vote bundled together. And but you do have uh kind of two more things that that are going on that I won't say too much more about. Um and yeah, small aside about this is that uh this is basically what Justin was saying before. Um given that we want dynamic availability so we want this uh property that the chains still make progress uh even when we we cannot finalize we have

less than 2/3 that they're voting SSF does not mean that we don't have reorgs. So same single slot finality versus three slot finality doesn't have this kind of fundamental difference of you know somehow magically single slot means that there's no orgs like that just isn't the case. Uh so actually the trade-off difference between 3SF and SSF is really just uh that in one case you you are um having a smaller block time um and but you accept like a longer finality time and and vice versa and uh yeah so the on the leader selection side we um kind of discuss u the complexity was mostly on the on the incentives um then there is like u some

consensus complexity that's kind of shared by uh both of them like no matter uh you know which of the two leader selection mechanisms you choose you kind of inherit the same uh consensus complexity from just from the the underlying like 3SF or SSF mechanism uh one of them is just these two phases that that I mentioned before uh that you add to the slot. So this confirmation phase which is what you kind of use to to get to this orange confirmation state. Um and it's kind of necessary for reasons that I I don't have time to to get into. Um and then this freeze phase which is basically this synchronization mechanism that's meant to replace proposer boost and like in some ways be better than proposer I mean in a lot of

ways be better than proposer boost uh but also just extra complexity and it doesn't have to be exactly this mechanism but we generally know that uh all all dynamically available protocols around have something that looks like this like some kind of synchronization mechanism so likely there has to be some pin there that that's put in the slot. Um and then there's the the the main thing is for again reasons that I don't really have time to to explain uh but like security related let's say um you probably would want to bundle this like big consensus change with uh a quite big change in the way that FFG and LMD goes interact which for people that are

familiar with this uh it's removing for choice filtering but yeah I would assume most people are not familiar but just think of it as like a really big in some sense um kind change deep in the way the the force choice works. So it has like a lot of ramifications and kind of involves a lot of um complexity and uh yeah finally so this was things that are um that's consensus complexity that's kind of shared by by both the uh cup value set and orbit mechanism whereas there's a bit of uh complexity that's more just um specific to orbit and in its relationship with the with the consensus protocol. Um and so specifically this is because of the the uh this like uh committee rotation um

just the fact of having committees and and the fact that these committees are unlike today's committees responsible for finality. So um you really like as Barnabas said like we we don't get finality once all of the committees uh speak but after a single committee speaks. Um and this means that we can't just rotate kind of carelessly like we do today like every slot or you know over just a period of time uh because that would essentially break finality like you cannot have different committees finalizing different things. Um and this generally is is somewhat challenging even even just uh rotating on finality. So like once you finalize um you you just change to the next committee doesn't quite work. It seems

like it should, but uh we uh basically it fails because we don't have a a unique notion of the next finalized checkpoint. Um like very quickly here you can see uh there's that A is finalized. There's this uh link. Uh but maybe this link is not it's it's not known at first or in in some uh kind of part of the network uh people don't know about this link. uh C also gets finalized and depending on what you see first or what gets processed on which chain first uh you might basically do the committee rotation in a different way because you've first someone might see A as the next finalize and someone might first see C um and this is kind of a yeah just a property of how the the

current consensus protocol works which can be changed but with some cost uh so yeah this is like a big kind of source of complexity added to all of the general like rearchitecting of the of the consensus protocol. So far the the best solution we've seen is uh basically trying to get actually this u single not like unique notion of uh next finalizer finality height and yeah it would basically involve uh a testing with a finality height and also adding a new slashing condition that's kind of uh related to this. Um, and this, yeah, it's it's somewhat messy and I mean hopefully there there's other solutions, but so far it it's definitely added some some complexity to the the whole work of

like trying to spec out um something like 3SF and so we've been like also because of this just focusing more on the on the simpler version which I think anyway u basically all of the things that you need to that you need for the orbit version of all of this like you also need uh for the sorry uh all the things that you need for the the easier like the cap version, you also need for the for the orbit version. Um, and yeah, with that, I would conclude and pass it back to Barnab. Yeah, thank you so much, Franchesco. Uh yeah, I just wanted to bring it back to

to this question that we started from on the on the home nodes and maybe what the what the picture looks like for for them in these two different uh proposals orbit there validator set. So it's very clear since orbit allows this rotation that the validator set can be can be much larger and what this essentially buys you is just direct participation of nodes including uh solo staker which I represent here as people who have their own node at home. So like purely uh untrusted uh independent nodes and who also uh bring their own stake. So that's the situation that's yeah your life gets

a bit easier because you can enter directly into the into a validator set. Um the models that seem more favored in the in the cap validator set world um especially if the cap is fairly low though as Justin mentions in the chat it's also possible over time to to to increase the cap. But the models that seem like more more appealing there are either a combination of uh distributed validators. So you have several home nodes that are essentially hiding behind uh a single logical validator that that makes the station. So you're not directly like participating in the validator set but you are indirectly by

participating in that in that network which is more let's say offchain. Um and the second mode of um of participation could also be um something that looks more like uh delegated staking on on home nodes. So we have protocols today like to receive uh the delegated stake that they need to to reach uh the minimum effective balance which should date 32 but would be dynamic in a in a cad data set world. And yeah, the question is are these options like uh satisfactory enough? Like do do we are we very

attached to to the solo sticker model as opposed to these more like home operators uh in in different uh configurations and yeah I think that's basically the crux of of this uh of this decision. Uh yeah I wanted to just open it up a little bit. We have uh 7 minutes left. So we we can we can discuss for a few a few minutes on on this. If anybody has thoughts, please write your hand. Orans if you saw something interesting in the chat that you want to highlight.

Um yeah, I mean there's for example there was the uh conversation around what the cap model would mean effectively for for the the the minimum balance for for participation, right? And so how that depends on to what extent there will be consolidation or basically um delegation to to to to a few very large entities or more kind of equal distribution and potential griefing attacks and and all these kind of things. So maybe yeah, I don't know if you have some more thoughts on this. You already touched on it, of course. Um just go is this an answer to to these questions?

Uh no it was something else. Oh I see I see. Yeah I guess one of the one thing to say is we do have like some control parameters. So setting the slot time to some value means that you have you give yourself like more room to have maybe more validators in the cap. I think the griefing risk so big validators splitting their ST across many uh many smaller ones to like push out uh to make less seats available for for smaller validators to come in like they can happen. they feel like part of the defense to me feels like it relies on the social layer to tell people yeah you

should uh consolidate and making that easy. So in protocol like now we have maxim um in the future like I discuss even and training more of these delegated prostate type uh infrastructure to to make that even more legible uh and easy to to obtain. And then the second layer is more about um yeah um defensive in the sense like you you could you could imagine something like a a fee or per se but I think that that starts like to make the the incentives um pretty really pretty tricky but we we also have the opportunity to to reduce the risk of people having more stake on a on a single seat like we've already

done it with Max CB by removing or reducing the initial slashing penalties and increasing like some of these thresholds. I think as long as we keep the guarantee that yeah one/ird at least one third of the ST is slashed when we have a finality safety fault that seems like a good enough condition and we can play with the with the other parameters to to make the proposition more um more appealing. Uh maybe Franchesco first. Uh yeah, I just wanted to say that to me feels like and I am partially why I'm I'm kind of excited about this call that the answer to this like um to you know is the is the cost of worth uh worth

worth it is very much dependent on what's the timeline like if you were to say that the timeline is um probably even like two to three years I would say most probably not um I mean maybe it's not even realistic but if the timeline was 5 years then yeah I mean maybe or like at the very least um I think it would be a much less pressing question to even come to a decision on this. Um, and yeah, it would be it would be much more okay to kind of keep uh working on both things in parallel or maybe keep working on the easier things but like build it up and eventually uh be able to figure out what's what are the missing pieces to uh to go beyond that. So I think yeah really depends on that as well.

Yeah, makes sense. And I wanted to prompt you as well on the on the confirmation. So let's say we we're not so much in a hurry to to move like to to SSF and it's it's been discussed a little bit in the chat like there's been this work on on confirmation rules that that exist but that just hasn't really been deployed. Uh I wonder if either you Franchesco or I know PUS has also worked on it. uh can tell us a bit more about yeah how much mileage can we can we get from from such an alternative? Yeah, I mean I can um quickly just say kind of um what the the thing is about.

It's basically just a way to um use the votes that you see in a slot which is already like a significant portion of the valer set uh voting like I mean 132nd but it's still like um a lot of that that's that's voting and it's sampled with a committee so there's like a lot of security there. um it's not slashable security. Uh but still to to basically get gu like very quick guarantees on the on the safety of a of a block that's been just proposed. Um and it's kind of like parameterizable depending on uh basically the kind of adversary that you're worried about. So depending on how many how many um how much voting weight you see um and I mean some some other like more like technical

things. uh you can basically get a u number that tells you like supposedly under these assumptions this is the the highest uh adversary that you can tolerate. Um then in practice I u not entirely sure it's not something that I followed the development of uh much in the in the last I probably year or more. So maybe pus can say uh more concretely about like what's going on there with the I think you mentioned in the chat that prism uh has an implementation of it. Um so yeah um yeah both left maybe I can give a high level of details so we have an implementation we have been testing it for a while but because of like petra and other items we kind of dropped the

priority so now petra is on the door so we'll probably prioritize it in the next coming weeks but yeah so we have implementation we have been testing uh as far as I know prism is the only consistent layer client team that has it so I would love to see more client teams jump on board so I mention in the chat Roberto Muel and myself are in in like this working group that works on talking about this implementation. So yeah, if any client team is interested in implementing it, please let me know. Yeah, thank you Terrence. Um, cool. Yeah, I noticed that we have one minute left. I hate to stop good conversations, but I I think it was also part of the fun of this call that we had like so many topics and I hope that gives you like a sense of what happens in the in

the head of a researcher for 90 minutes. We just bounce around between different things and try to uh explore all the angles. Um to keep a conversation going, these are a few suggestions. We have a new protocol research call channel in the ER&D discord server. Uh we'll try to make it live. Uh I'll post an magician thread with the slides material, some follow up on on these questions and feel free also to comment directly on the if research posts. Uh there's one by Tony, two by myself. There's a new uh tag for for that. I'll leave it to Onsgar to give us a teaser of what the next call could be about.

Yeah. Um awesome. So next call. Um so we we want to have these calls once a month. Um ideally um the the rhythm we want to aim for is always the the first uh Wednesday of the month, this time slot. Um we probably lock this in soon. Um but so if you have feedback that this time is really terrible or something of course do do let us know but but we kind of currently aiming for that and so the next goal then would be May 7th. Um and the topic there can you go to the next slide? Um so basically if we go back to this uh this this rough um picture here I actually would want to to basically specifically here. Yeah exactly focus on um this one uh bottom left quadrant here for the next call the the execution um throughput. Of course, we already

touched on some topics there specifically around um leveraging more having heavier builder nodes than than what is necessary for for just uh validating. So for just executing and so so there's a few features actually in the pipeline right now. Um some of them leveraging this, some of them in general just uh trying to to to get us more execution throughut. in a way like a lot of pent up lowhanging fruit feature overhang because we just have not um not not focused on this for a while um focused more on on on other topics um on the L1. So this is just a non-conclusive list of of of topics that that we might touch on and that that basically I see at least as potential candidates for the

the the fork after after Fusaka. So Fusaka is already pretty locked in with the feature set. So that this is the first kind of open fork where there's still room for new features. Of course, we could not do all of them at once, but basically just to give you a bit of an impre impression. So delayed execution meaning um basically you um give yourself more time to actually run the the execution payload of a block instead of just a few milliseconds. It could basically take several seconds to execute. You just have to be done by the next slot. Um here to mention that EPVS which um POS has been championing for a while is a bit of a compet competing feature there. somewhat different in in in what it gives you, but but but it's related. So So it's not clear that we could do both. Maybe we would basically

have to have to figure out a bit more of the exact kind of comparison here. And then there's block level access lists, which are supposed to give you um better um access to state because you you basically you predeclare the block builder. It's one of those things with the block builder which they'll have to like go manually and slowly load all the state from disk when building, but then they would basically um attach a list of all the state accesses to the block that they created. And that makes verification faster because you can basically prefetch all of that state from disk. Um some parallelization. I think the general sentiment is that you can't get too much of a multiplier out of parallelization but maybe say some sort of threethreaded um parallel execution. So specifically like a factor of three in terms of compute throughput.

Um how how could you make that work? Um then there is P2P improvements specifically around uh bandwidth um needs. So can we basically somehow reduce the kind of the multiplier used for for propagation? Um right now I think that's that's that's an average like 8x kind of overhead in terms of how much the size of a block is versus how much you actually use in terms of bandwidth when propagating it. Can we get that lower um without kind of latency um issues? Um and then uh compute gas price harmonization. That's the one effort that's already the the the furthest along. And we have an active kind of resource pricing breakout call and that David is is is is leading and that that specific topic of compute gas pricing harmonization has been

championed by people from Nethermind and and some other people. And basically the idea is just make sure that all compute costs the same in terms of like how many milliseconds um it takes so that you can basically you don't have like individual pre-ompiles or something that that are way too cheap compared to everything else or other compute operations that are way too expensive. H call data gu I mentioned which basically gives you a much better handle on like um using the the the available data space on the call data side efficiently. Um, and then the last one I wanted to to mention, it's a bit bit of a of an odd one out here, but um, Gom has been championing statelessness for a long time. Um, with with potentially vertical trees, or there are also other ideas how to get there. Um, that one would be something

that's like a much bigger feature than the other ones. So, that's probably not something we could combine with too many others. That might be an alternative vision of like basically focusing on this one instead of kind of like an um, some sort of mix of the other ones. Um, and there there's quite a few open questions specifically around like what would that world look like? So, so that's that that that might be like a really interesting kind of like alternative vision to to contrast these others too. So, that's kind of a bit of a preview. If if that sounds interesting, h I would hope to see you on next month's call. Oh, and the last thing of course and also if if there's something maybe that's not on the list that should be on the list or or other things like do basically feel free to reach out,

propose these things. And we'll have another eth magicians thread um with where you can propose extra extra topics and if you want to maybe give a presentation on on a related topic to reach out and next call I will lead most likely not bannabe. Um so so yeah reach out to me and and and yeah awesome. Yeah thank you so much and thank you all for participating uh for the first code. I hope it was a a good experience. All right see you soon. Bye. Bye.