Consensus Improvements Roundtable: Shorter Slots

Transcript

Thank you so much. Congratulations to everyone who made it so far. Uh it's been a very long day and great to see the room being very full. Uh our very last event uh is a second round table uh where we have Sean and Bad co-odderating. Um Sean, do you want to kick us off? Sure. Hello.

So, I'm Sean. I work on a lighthouse at Sigma Prime. Um, so I've been thinking about shorter slot times in the context of like what can a beacon chain do and what can a beacon chain do in like the short term then also like what is optimal. So, um I was hoping we could discuss yeah I guess shortterm what can we do sort of low hanging fruits for Ethereum today and then what is also in a beacon context and what changes in a in a beam context. So yeah, anyone have any thoughts?

I don't mind starting us off. Um so I think today we have 12 second slots and we have some understanding of when messages are propagating and how long they take and we have a sense that there is like slack in parts of the slot right now. So we could take like a very simple approach and just change a single uh constant which is 12 second slot time and keep the rest of the slot just like proportionally the same as far as when we're propos or sending messages. Um, I think in there we could get to maybe 8 seconds, six seconds, um, relatively quickly, like maybe in the next hardware.

Um, and I think that's maybe something that is a low hanging fruit and something that's easy to coordinate around just because it's conceptually simple. Um but on the other side of the argument um is changing the slot time in this way uh too invasive to do when we could maybe lay the groundwork for more optimally adjusting like how a slot is structured. Um yeah. So the way I think uh I see the sloft from one of uh the research articles is that you know there is basically a delta to the latency and uh in a slot current

slot we have three deltas. So if basically you assume that okay you know uh the nodes will process everything faster generate block faster and do aggregation faster. So you have basically three delta and that uh for each delta in gossip sub you have about six uh hops right now which could be maybe 600 700 millconds and if it was three times that so basically you have about 2.5 second slot you can essentially have that and uh yeah but if you add proofs aggregation no non- entr becomes four delta so you can probably do to a 3 second slot as well. I think

so. But uh if we can actually drop the number of hops for example that you know the strategy where you can form a grid and say that okay in two hops you can distribute uh the signatures to everyone. Uh so basically you can then further drop it down but uh question is yeah so how how do we do that? Uh yeah. So I think an interesting thing there is like the the number of deltas like can we reduce the number of deltas and there's been like a lot of talk lately about um EPBS and um delayed execution.

Um and I think the idea there is to maybe overlap two of the deltas where we have like the message that you want to attest to sent around first which is maybe just a block header and then you can and add a station for that and as you start seeing addations then publish the full block blobs and in parallel add a station can be aggregated. Um so is that like the type of slot structure that makes sense? Is that like more close to what is potentially optimal? And then additionally like it seems like it might fit in well with with ZK proofs where you send around the header while you're generating ZK proof and then this overlap in time between like the vote

aggregation rebroadcast can also be done in parallel with like the proof generation broadcast. Yeah, maybe to um ground the discussion with what are the proposals. I feel like everybody wants both to restructure the slot because we need like this delayed execution uh for proving and other things. Um everybody also wants to shorten the slot time. I think at the moment there's a debate um around do we shorten the slot time first and then do the restructuring or do we do the restructuring first and then we shorten the slot time and so one question I have I I'm a proponent of shortening the slot

time first because I believe the effects are very very important and getting them sooner is very good or at least like would be a huge win um but a question that's often come up is let's say we don't research of the slot first and now we have like the current structure. So proposing attesting aggregating the proposal that we have is to do 3 second proposing 1.5 second at testing 1.5 second aggregating is that doable like we don't currently have hard numbers and looking at chaba's slide it looks a bit optimistic to do 1.5 second testing and so I'm wondering like if you know um yeah better numbers or if you would

propose like a different partitioning of the of the slot assuming we want to It's going to be six contract targets. That sounds like a a reasonable formula to me. Like three 1.5 1.5. Um, but I don't know. Tough to say. I think perhaps with some more of the P2P low latency toolbox, it's achievable. Um, it seems like the the simplest low hanging thing though would be like it feels like there's about 4 seconds that you just like take out a slot. you could still have the same proportions and um so that might be the easiest thing to like start with.

So once once we have delayed execution then we don't need to allocate extra time to block building. But on delayed execution like there's block building time is usually in competition with execution time like you have essentially like a lot of time for propagating. So you can have like more blobs for instance during that time you could execute if you were receiving like the execution payload. Then there's arguments for why builders might want to send the execution payload still as late as possible within that time. Um but after this propagation and potentially execution time then you have execution

time until the end of the slot which needs to be both for the nodes to execute so that they can attest their view or propose the next block and also for the builders to uh to build the next block either locally or externally. If you do externally it's maybe even worse because then the builders have to build the next block and also participate in the auction. So there's like this extra trips but yeah so this might be like a small part of the execution budget but yeah essentially these are what these delayed execution proposals do and that's also where you would have this extra approving time for the for the provers because once they get the execution payload as a as an output

uh they can immediately start proving if they were separated from the builders but as I understand there's also like people making the argument that provers and builders shouldn't be separated so that they can start proving as early as locally they have the block and that might be the best combination. So even if we are to like try to separate them in protocol like the economics might be towards just integrating because having the input locally allows you to just prove faster as well. But yeah that's the general discussion I think.

Yeah just is it correct that um from your perspective you think APS has been de prioritized in the short term? That's question number one. And question number two, do you agree with this take that the more we shorten the slot times, the more we shorten that we reduce the uh slot to pin ratio, the more timing gains become important and therefore the more APS becomes important. And so if we if we're thinking about this this endgame kind of slot duration, we should actually assume that APS is there because this the timing games will become really prevalent.

Um yeah on APS I think once you start thinking that shortening the slot time is a very strong objective you start looking at things that stand in the way of doing that as potentially bad and APS means that yeah you need an extra round of things so you have like a beacon proposer then an execution proposer so it means like you're essentially doubling the the distance between blocks or you say no do we have overhead of EPs as well in EPs is a little different because it's the builder role that we are taking out and it's not the proposal role and I think that actually makes quite a bit of

a difference in the overhead of coming to consensus on one versus the other like we would want to have a full round of consensus on the output of a proposal in EPS which we don't really have on the builder in EPS like we just have the PTC that's doing um availability committee essentially. PTC, right? Um yeah, that's an interesting question. I think we would still need to have uh I'm not sure. Yeah, I want to think about it. But another reason that maybe was de prioritized is feeling that one

of the main consumers of APS would be precoms and feeling again that shorter slot times address the need for more prest in the system and so that made it maybe a little less loadbearing. Yeah. So on on pre-cast the story that I've been telling is that um if we reduce the stop durations in a very decentralized system like Ethereum we're never going to get it less than let's say 1 second and 1 second is just very very long compared to for example and so Ethereum is just going to always lose unless we embrace the preformationations and so I'm almost tempted to say let's go all confirmations because that's the only

route that is that is going as to when uh yeah yeah yeah I think that's a that's an argument I I still feel like you can have preconfirmation systems without having APS necessarily like APS just removes the role out and like specifies it in protocol but I think it's possible like if we're willing to beat the extra possible centralization pressure that we just keep the role bundled with the validating group and that might be a possible way of doing that. It just like removes some latency of having like two different parties in the in the same block. And then there's a question around timing games. I also

like revisited a bit um the the thinking around this. I do think it can be a a problem to like the consensus. Um but I also feel like there are interesting impacts of timing games. Not to glorify them, but like for instance, Solena has a the inverse leaderboard that we have like they they they celebrate people who play timing games very great and the reason is because it it shortens the transaction latency between the sender and the inclusion on chain like the confirmation. Like you when I send my transaction within the slot, it can go immediately from like the builder to actually being um confirmed on chain.

Like that's one thing that they um find improving. You seem I mean the opposite like timing in is all about delaying conclusion until the very last minute so that you have more transaction more. Yeah. But but if everybody's delayed by like 3 seconds you mean that whenever my transaction comes into that interval um it's it's yeah it's just shift independent almost. But what timing games do is they force uh the block proposers to reduce as much as possible the latency between their block being produced and their block being like communicated to the

network because the longer that latency is the more me they lose uh during that interval. Um so it doesn't really actually matter like where the deadline is. what what matters is just like the latency between the block being ready and the block being like uh sent to the network and and confirmed. So yeah, I don't think we should go to that extreme like but at the same time um I'm not completely convinced that timing games will necessarily like deolve into the consensus being completely broken on any reasonable time scale. So yeah, I I don't know that we should be like so overly worried about them.

I have a bunch grab bag of silly comments. One is would you consider 7 second slots because it sounded like uh uh six might be a little slow. Eight everybody knows is going to work, but if you looked at the one there, it was like 1.9 was where the 1.5s don't work. So, it looks like you could probably just do seven easily and uh and it's like not as nice of a number, you know, it's it's odd, but anyway, uh it's just worth worth mentioning. And personally, another question I would have had to the whole room is does anybody so far I haven't heard a lot of appetite of thinking that restructuring the block ahead of time is important. It sounds

like if you can reduce four, five, six seconds just naively by just reducing it. Does anybody here think that that's a bad idea? I haven't heard that yet. Like the counterargument strongly. Um, and then finally, yeah, it's like for this thing you mentioned, it's like with the timing games, it's like the difference between the bus leaving and when the doors of the bus close. So the bus always leaves at the same time, but the timing games make it so the doors of the bus close very, very close to when the bus leaves, and so more people can get in more often right at the end. So yeah. Anyway, those were my random comments.

What do you mean restructuring the book? The restructuring the EPBS orate execution. Yeah. Yeah. These like changing how the like instead of just Yeah. Yeah. Like how when when different parts of block production life cycle happen? Yeah. I I can leave the mic but maybe the I think it's the same answer to both uh your first and your second question like why we wouldn't do seven seconds and everyone is happy or why we should think about restructuring. I think at the moment there's just been a lot of work on restructuring like and it's been talked about for a very long time. So there's a lot of code that's already ready. Uh I don't think people are like blocking on six seconds being like oh this is pushing it too far. Actually

people are fairly so far like in my interactions I've been like fairly eager to explore whether it was feasible. I think the problem is just that the work of moving to the shorter slot times whether like 10 or eight or six just hasn't been done. So there's a lot of code that's still missing. it's not impossible to deliver it back at Amsterdam like if we were committing to it but there's a lot of momentum behind the slot restructuring proposals and so that's also an argument for going for the option that seems more readily available I think so yeah it's not really a matter of like 10 or eight or or six in my opinion at least I I also have a I I'd like to comment explicitly about

the quoteunquote as far as the um I forget which adverb you used. I I apologize, but as far as the quote just or or simply or something, right? So, and I'm not saying this is a bad thing and I think and I I I'm for reducing this lot of times. I want to be clear um like I guess you know as described by the people here. What I want to say is that it is not clear that it's a simpler option overall in terms of implementation and and and the the general idea is and I want to kind of reframe this and this is the frank reframing I tried to you know uh push but is to say like it doesn't we could double the slot times that would be approximately as far as having the slot times and that is the key thing here it

is it is the hard thing is not shorter the hard thing is variable when people say shorter slot times the way to read this is variable slot times and that is what No, I mean right now a lot of the clients work in nosis, they work in minimal uh preset and that's fine. 5 seconds, six seconds, it we know it works but areas the test nets, dead nets have run uh faster for perk nets, right? What um um it is a much less global change actually whether it's 7886 or 7732 some of the other proposals virtually all of them are in a lot of way actually a less global sleeping change than simply reducing spot time and one can get into more details but that's the gist so

totally fair yeah and I would say on this particular question the work of changing the time will have to be done even if we do seven seven I no I I I agree with you, but I'm saying in terms of the it's one of the and I know this analogy has come up in various sorry in in in various um places but to for anyone like but that there was a now slightly infamous EIP7549 from the previous cycle that was it looked really simple to people and and this now because of that experience we all now are you know watchful for these things but but the point is like it the idea is it's it has that deceptive quality to it and and it's not that bad.

It's not that won't have to be done. It's that in terms of the it is not nearly the obvious prioritization of to get the end result we want. Do that first because that's the easy simple thing and then we do the like tricky little thing of of or the of the tricky thing of like we stop sloppy structuring. um that there it's actually quite a bit easier to have the slot be structuring in certain ways um across the like um from one fork to another to just say well now we have a new slot within the slot loop because it only affects that as opposed to like a global view of of the chain and maybe something that I think is a bit missing in the discussion as well is why we want shortest time so perhaps I

can take two minutes and could I use your laptop to I'll find the proposal that we made for glam because I feel beyond like the implementation details that anyways we're going to have to pay at some point it's really a prioritization problem and and I think that can only be solved by asking ourselves what do we need the most uh not today because that's not when ships but uh hopefully uh 9 months from now so there's a small bucket list of things here.

Yeah. To my my main catchy phrase is to say shorter slot times make the Ethereum confirmation engine better and that has just flow on effects on many different parts of of the protocol. So the first one that I think is very important is just UX. So your transaction confirms faster like you get some kind of tick faster. in particular with 12 second slot times on average you get confirmation in six seconds. I've learned recently from someone at Coinbase that um users think there is a problem with their transaction or with whatever they're doing like on digital interfaces whenever the system is unresponsive for more than two to four seconds. And so if we were to have the slot time to six seconds, the average uh

confirmation would be 3 seconds. uh which puts you like exactly in like the the sweet spot of yeah the user not crossing that chasm of feeling like oh something went wrong and I need to to take action um as the first one uh second one is better censorship resistance like you have two times as many block producer per unit of time so you have just more opportunities for your transaction to to come on chain I think this is not negligible at all um another argument is about apps uh getting just fresher data like more often their data is refreshed. So for instance, dexes, they they're quoting better prices most of the time, which means that they're losing less value to the outside that has more upto-date

prices, which means that more value stays within the decks, which means that you have more liquidity providers, which means that the spreads are tighter for users. So you have lower fees on on these on these apps. And you can make similar arguments for any app that relies on some kind of oracle to to bring information on chain. You also make the units of work uh that happen like every 12 seconds smaller. For instance, block building auctions or networking um load. Uh which means that yeah, typically it's better for a system to have like smaller uh more frequent things happen than bigger more infrequent things. That's I think um easy to understand. Another big consumer

of shorter slots is interoperability protocols. like a lot of them rely on just Ethereum producing blocks to confirm things or to settle things that happen like on different domains and they've told us a lot that shorter slots can be very meaningful. Um yeah, so I think I I hear the days when they say there's been a lot of work on the on the restructuring and at this point we should just ship it because we are sick of hearing about it and I I I'm also sick of it. So I would really really want us to have like restructured things but I actually think like this is even like going to 6 seconds would be would be very meaningful uh in the in the shortest order possible which is

blamster and I was more on the camp of actually saying let's wait until we have our shiny new consensus mechanism that perhaps like behain will ship to then deliver like these shorter slot times and just like delay that until then. But I actually think like from everything I hear and from yeah just all of these arguments that I've tried to to list here that it would be like such a meaningful thing to to do in in Amsterdam. So yeah was my like two minute propaganda pitch for for the update out of schedule. Um yeah, but uh I think this this makes it very valuable to me and to have these discussions and to accelerate like the work that goes into figuring out like how much work it is for clients to change this because I

I do realize that it's a lot of work like it's not a oneline change for sure. uh to also understand for each of the restructuring proposals how they fare with slot tanks like do they put us in let's say corner solutions that then get difficult to come out of like it doesn't seem to be the case but I think it's meaningful to think about them together um and third to also yeah for planning purposes like we we should at some point decide what goes into Amsterdam and commit because everybody wants short forks that come earlier rather than And so yeah, having these discussions now is just like very important.

Yeah. So one thing I to add is that the shorter the soft time the more you have different type of activities in the client overlap and the more you have these overlap uh the more you have resource management problems. at the node level CPU disk uh memory whatever garbage collection me database compression uh all these kind of things uh are getting compromised which should be still fine uh for example if you're running a dedicated node but if you're not running a dedicated node but your node is doing something else as well that might start to create issues

uh this is also very language dependent and very operating system development. So you start to be intell like some languages suffer more than others and uh and someic systems are more adapt than than others. Uh I don't know is this bumbly I'm just saying shortening sometimes has this kind of effect of of more effort needs to be done in the program in resource management uh so that pri which just got in cases. Yeah.

Also, I think related to Saba, um I'm part of some of the homestaker communities and I think there's um there seems to be issues with Australian notes where they they tend to get like you know like some inclusion latency on their attestation even with 12 second slots. So I don't know if like shorter slot time might actually impact those um yeah Australians specifically maybe from so yeah so sigma prime's Australian um and we run nodes in Australia and there is like a quantifiable difference like like

monetary difference I don't know the numbers off the top of my head though I imagine shorter slot times would make worse like exacerbated but I I don't know to what degree the community balance out yeah exactly um there were some numbers from uh uh from Nero uh from Tony right uh just the other day and he also measured Australia and central Europe like uh you had some comments on it maybe like it wasn't I'm sure somebody discussed it with him on Twitter but um yeah so Tony uh made the version and there was like a significant it was um it took much longer not just in Australia but generally like longer than

we expected to arrive at 90% throughut. Yeah. Yeah, I think we need a lot more of his analysis and like precise one and then for instance Java was presenting like optimization for get network hopefully these are things we can do before glam 7 so that even if we are like at 90% confidence but we feel like we can get to% by the time we get there this my like a hopeful thinking right now there is the perfet and bloet right And it would be cool to utilize those or maybe another one to see also the and one question there is also like how we want to ratio the gas limit like

whether we just want to keep the same gas per time or we want to use it to scale as well. uh basically. Yeah. So in my in in my view these were like stupid like metrics. I you keep them the same and just try to make granularity higher. That's that's challenging enough. Let's let's let's keep So do you think uh Starink will sort of improve this because their latency uh that they advertise is like 16 millisecond app. So basically I think this is round trip. So one side would be 30 compared to what like compared to

compared to uh going from for example from Australia all the way to North America right? Yeah. So you can do lower bits lower bit kind of shortcuts but I wouldn't count on them for setting up I mean stalling could be I mean it could uh change uh uh basically the topology of the network in a very viable way. Uh I I tried running node on Starlink from Indonesia and it didn't work like I had troubles getting peers over over Starlink. I tried VPN. I tried some like networking tweaks, but it didn't really work well.

Yeah, I think you're better off just getting the fiber. And why why do you think that is because they advertise latencies? So, I'm I'm not sure. I just it was there is some technical issue with just the yeah the satellite internet maybe, but I managed. Maybe they are censoring you. Maybe I was censored. Maybe I but I tried VPN. I tried like somehow to circumvent it, but yeah. Um I don't I don't have the right answer. I think it would be interesting to have like uh Starlink is like some bandwidth requirement that we can build around like that's sort of the limit or so. Um but also I managed to uh connect to peers on a internet in plane. So uh I ran I ran a node in a plane. So the

satellite is not a problem. Y I think there are some uh lower hanging fruit that someone could do to um be more inclusive to those nodes in Australia or elsewhere. Um and that is uh you know in gossip you could uh instruct nodes to include other peers in their mesh based on the RT that they see. So instead of just connecting to like random peers which might be the closest ones, there could be an RT or latency threshold where you're going to connect to two peers that are 100 millconds away to be peers that are 200 milliseconds away and

two peers that are I don't know 400 or something. And in that case it doesn't mean that Australia is going to suddenly come closer but it's going to be more included in uh in more like nodes that are going to be included in meshes uh of other nodes and therefore you know getting the uh the messages will be equal to anywhere else or and then that's a very simple change or does it own low orbit constellation of satellites to sort of bridge everyone water of the world.

Yeah. Does anyone have anything else? Are we sending a note to Mars? Uh, yes. It's in the road map. Okay, cool. How are we doing on time, Justin? We can wrap up now. Okay. Well, thank you everybody. [Applause] Yeah, thank you everyone for coming. Um, it was definitely helpful for me. Um, I'm hopeful to have at least one Beam day uh every year. Um yeah, I was hoping to organize a beam week uh before death connect, but a

couple things happened. One is that um I was told there might be an interrupt. Uh and the other thing is that um I'm a second child around that time. So I don't want to commit to but yeah uh overall um I am expecting to spend more time on on the beam project and um I am hopeful that again they will age like fine. So thanks again for for all the uh team work that that that's happening behind this. It's amazing to see uh about 50 to 60 people here from from a dozen dozen teams. Thank you.

Thank you.