EPF6 Office Hours | Barnabe

Very well. Awesome. So yeah, thank thank you so much for joining everyone. Welcome to our last office hours AMA in this cohort. We are finishing the uh office hours special guests with uh Barnaby here today.

Uh our last guest to to send us off to to Dev Connect and to uh the the code followup. So thank you so much for joining today. Appreciate having you here. Uh, one last special guest and uh, yeah, it's an honor. Uh, I mean, we had Barnaby couple times before.

I mean, Barnaby was always really nice and open and joined us a couple of times in the previous cohorts, but it's been a while and a lot's changed since then, I believe. It's been it's been um, moving only faster and faster since uh, I think we had you in the cohort 4 last time, so like more than a more than a year ago already. Um, so uh, yeah. Um before we get into the the present and the future uh let's talk about uh bit more past because I mean many things changed. So Barnaby today uh is leading the protocol architecture team uh before he's been part of a rig and um uh I mean I I remember following your work as um maybe the first thing that I that I followed from you was the uh 1559 analysis uh before uh before London.

So like four or five years ago at this point. Um and since then of course the consensus and and rig and many things happened but um I'm wondering what led you to this what you did before how did you joined uh EF and Ethereum if you can tell us a bit bit of your background to get started. Yeah, for sure. And first, thank you for having me again. Always appreciate talking to to the fellows and and it's been great to see from the past cohort people who've stuck into the ecosystem and done and great things after that like it's it's been super successful.

So yeah, hoping the same for all of you. Um I've started getting into Ethereum crypto I guess around 2018. So at the time I was doing my PhD in Singapore and it was on game theory and my PhD advisor happened to meet completely randomly like Vitalik in a in an incubator. Um and Vitalik was like whiteboarding and there was like a a game theory equation like around the Sharley value I think which is like a cooperative game. So they were designing the incentives of of a proof ofstake mechanism that they were working on.

Um, and my adviser was like, "Oh, this is cool. Like, I I do game theory. Like, we should talk." And so, he started talking to to Vitalik. And there was a couple more people in the room who you may know.

I forgot who they are, but at the time, like some of the designers of POS. And um, my advisor told me about it and I was like, "Oh, this is cool." Because I just heard about Ethereum like last week. It was like, I think peak 2018, like CryptoKitties or something was happening at the time, so it was getting more mainstream, I guess. Um, and we started like thinking about blockchain more with my advisor, talking to people at EF.

Over time, I joined Devcon. I was just like hanging around kind of at the edges. I still had to finish my PhD, so I couldn't split my attention uh too much, but yeah, progressively ramping up. And when I was finally done with my PhD, I basically applied for a full-time position at EF as a as a researcher. and I joined this new team at the time which was the robust incentives group.

So the team that was really dedicated to like incentives and end game theory. So yeah that's how I fell into it.

Awesome. Thank you so much Barnaby. Yeah it's um I believe it can be a big inspiration also. Thank you so much for saying that. I mean you see the follows from the previous cohort and maybe we have also some some Barnabies in this cohort listening now like uh I want people to get inspired by the journey because it's been it's been quite a while then I mean uh like was it six seven years in Ethereum now and uh and still counting um so um so it's exciting and and uh so you mentioned the rig and uh I believe some people are familiar with that but if you can elaborate maybe more a bit on uh what was the Rick team like and how it evolved to protocol architecture like how did how what was your transition like?

Yeah.

Yeah. Yeah. So at the time before I joined there was a team at EF that was basically EF research. Um so it was like Vitalik, Justin Drake, Danny Shawe. um a lot of yeah people who are fairly wellknown um and as the team was growing like they realized okay we have to on board more people like and especially like on on specific domains like economics or or consensus and so or security and so there's I think at the time so rig was started maybe right before or right after there was also like another team which was the cryptography research team that was started and another team which is protocol security.

So, EF research kind of like split into uh into this cluster of teams that was really dedicated to like novel ideas and trying to take that research and put it into into production in the protocol. So, rig was fairly small at the start. It was just me and a couple of other people. Um after co started basically a few weeks after I joined EF. So for a long time it was also like a lot of just like being completely remote not meeting anyone.

Uh it was sort of a strange time but coming out of that I felt okay it's time to like grow the team. Um I was made the team lead in the meantime and um and yeah we I had started to work on the proof ofstake incentives as you said Mario also like EIP1559. I was doing simulations and the more like I was looking into stuff like the more it was very clear that like cryptoeconomics is such a big part of the protocol that we we need to have like much more um people like dedicated to thinking about this stuff. So yeah, over time grew the team um until basically 2024, so last year. And then we had like a a bit of a a period of upheaval, let's say, where for the last year like a lot of changes happened both in the ecosystem and internally in EF.

So one of the main triggers I guess is Danny Ryan who was the the research lead of like EF research um left the foundation. And so this cluster of team which was like rig cryptography consensus and security and a team of research engineering like yeah suddenly we were like okay what are we supposed to be what are we supposed to do like a lot of people also last year um you know like they were asking questions about what is the direction of Ethereum like what is the northstar like what are we chasing after after the merge so so we tried our best like to to give these answers Alex Stokes and I took the lead of of EF research. So that was like at the beginning of this year. But then working on this we realized actually if we want to like ship these ambitious things um in the in the protocol it might make sense to think not of like there's EF research on one side and other technical teams at EF on the other side but actually like have like a a fully integral cluster of teams that's like both research research engineering engineering and just like make the the pipeline as as tight as possible. And so in June of this year we basically dissolved the boundary between Y research and other teams that became this cluster that's called protocol.

Um yeah and and since then like team Alex and I have been have been co-leading that and in particular I've been part of this protocol architecture team that's thinking a lot about like the how to put the pieces together between like consensus networking mechanisms and everything. Um yeah, it's been like a a pretty busy last year, I would say.

Yeah. Yeah, indeed. It was it was very busy like the whole um Yeah, I mean, so Barnaby uh was helping to create the whole new protocol direction of the EF basically and now leading the architecture. So yeah, thank you so much for for uh explaining all of that. Um that's sort of the Yeah, al also it's interesting that you joined the EF before the COVID.

I have the same experience. It was like February 2020 when I joined and then I haven't met anyone for more than a year. No conferences and I thought it's normal. I thought it's like you know it's all online anyway. So um that's uh it's an interesting experience but um that's so that was more about the present like currently we have this whole protocol u uh tightly integrated in EF which which uh which is a the strong new direction.

So um now uh turning towards the future, how do you see the future of Ethereum or what makes you excited? Where do you see us heading? Um uh like the the vision is clear, but I'm wondering you maybe more subjectively uh what are you excited about or what what are you looking forward to? Um yeah.

Yeah, I think it's been interesting. So one thing that was sort of a personal observation that I think also connected with other people is that the merge was like this very strong alignment point for everyone like for research for engineering for the community. after emerg was like a bit difficult to say, oh the future of Ethereum is like X like many people had like many many different answers and and it felt like on the one hand you had keeping the network secure and just like doing some of these improvements to it and on the other hand like you had more like the research thinking about the endgame of of Ethereum. And I feel like through this process of talking to the community over the last year and like understanding like what people wanted out of the protocol like we've realized there's kind of a middle that's important like thinking more about uh shortterm strategic priorities for the protocol. So we have like these three as part of our cluster priorities which is scaling the L1, scaling the blobs and improving UX and interoperability.

Um yeah, it's kind of sandwiched in the middle between just like keeping the network live and thinking about like this endgame oified um protocol. And I think to me there's still like this conversation of like is the future of freum just like a series of iterative [snorts] changes that look like we have these priorities and we just try to make these iterative improvements or do we have like a terminal vision of what Ethereum is uh and then we just stop and the protocol is oified and and we move on to either the app layer or like the infra layer with with rollups and everything. So, so I think to me that's pretty maybe meta, but what's exciting is like to see this conversation play out between people who think more about like, oh, we have to make the protocol like usable today versus people who think more in like these very long-term decades or even centuries of like Ethereum. I feel like myself for I fell more into like the the first side which is thinking more about like how can we achieve like strong progress like right now. So how do we fix like very glaring UX issues?

How do we scale a protocol like so that it handles the yeah all the user activity that is trying to get there. I'm personally excited by a few things. So what I'm directly pushing is this idea of like interrupt. So making it easier for users to like use Ethereum and also like the networks that are connected to it, the rollups. Um that has so many different like places that need to be addressed.

So one of them is just like at the wallet level like when you have 20 different versions of Eve because you have 20 different chains like that's really messy. Um when you want to swap a token that's not existing on the chain, you have to go on another chain but then you don't have gas on that chain. It's annoying. So there's like very like trivial things, not trivial because it's actually fairly involved to fix them properly, but uh but yeah, basic user problems that need to be to be addressed. And then you have stuff like way deeper into the protocols.

For instance, today Ethereum has like this 12 second slot time which is the heartbeat of the protocol. One of my personal like yeah priorities is to is to make that shorter and in particular like we proposed a few months ago like the idea or the priority to like move from 12 second to six second and so like the faster the base protocol is like the more like the the heartbeat of the network just accelerates and it it just like makes everything smoother and a little bit more uh responsive. So that's that's really important. And then even more long-term there's um other initiatives like improving the finality. So when the protocol like comes to consensus over its over its chain data uh that's a really important thing that the protocol exposes like to the outside world like that's how people know that Ethereum came to an agreement on on something and the slower that is like the more every other system that depends on Ethereum is is kind of yeah not great and so improving that is also like really really important and yeah I'm excited to just like go through this series of like improvements and just like try to make a few more responsive like more able to like come to terms with its own consensus and and everything.

I think that's really important.

Awesome. Got it. Yeah, thank you so much Barnaby. Thank you for sharing all your visions. Um definitely many cool things, many exciting things to look for to work on especially uh for the people here.

So um I just wanted to get some context from you and get some get some idea for people to to know what we are dealing with here. Uh so they can ask questions. Um folks please raise your hands. Don't let me take all the time here. Uh and take the opportunity to ask something yourself directly uh before we get into the details.

Uh Josh has a question. Go ahead. uh you talked about uh the merge and and the beacon chain sort of being like the shelling point for Ethereum and developers, you know, a couple years ago and and how the energy has sort of waned from that. Uh and it seems like the lean chain concept might be sort of the next iteration of of that, you know, merge 2.0 [clears throat] or something.

curious like what your take is on the lean chain and and uh yeah its future because it seems like you know proof of stake was a was a thing that was eventually decided that everyone wanted to do and and you know so there was a lot of energy that had to be put forth to make it happen but as things stand right now lean chain is sort of you know Justin's crazy idea that people are have a lot of excitement about, but at least within the EF, there's not a ton of consensus around it being the actual road map or direction. So curious what your thoughts are on that.

Yeah. Yeah. Yeah. That's a good question and I think that relates to this um model that I was presenting earlier of like there's this idea of having a terminal vision of a protocol that I think Lynch chain is much closer to like the idea of coming to the simple protocol or the most optimal one. Um and and maybe this other side of like yeah we have to push through on like just iterative changes that can be very significant but but that are more like let's just make a series of like local steps to to improve the the thing as is and I feel like having both is actually good.

Um I think at the start like last year when Justin presented Lynch chain um which was called beam chain at the time at at Defcon I think people were excited like they felt oh it's like interesting like there's a lot of stuff in that road map that's like good things like there were also already shortening the slot time getting faster finality moving to postpontoum so all things were like good goals and things that we we all want to achieve but I think people also responded maybe a little negatively saying that this feels a bit like trying to yeah emulate again like this shelling point but at the same time it's not really what people wanted which was like seeing us take action today and not like in in five years and it was a bit unfair that yeah Justin had one slide where it was the timeline of beam chain and and it was a bit like maybe an unhappy format and it shows like oh 2029 and I think people were like okay we we don't want to wait 29 like you have to tell us what Ethereum is going to do like next year or next month to to fix these problems that we're we're encountering and so and so I think actually it's like now more balanced like having both on one side link chain that is like yeah let's think about what the protocol should be in like this idealized world or where we have like all the time to like really figure out like the the perfect implementation and on the other side things that are more like uh scrappy let's get down to it strategic priorities that just like move us forward in the in the here and now. So yeah, that's one part. The other part is Len is also interesting because it's it's many things at once. So there's one thing that it is is that it's kind of a technical strategy like it's saying it's easier to bundle all of these upgrades together and to do them all at once. I think that's maybe a part where I personally feel that unbundling some of that makes more sense.

Like for instance at the very beginning like there was this idea of bundling the postquantum transition along with faster finality. In my head like these timelines are are not really the same. I feel like postponu might be something we need further into the future and fast finality is something that rollups are telling us they need um offchain systems are telling us they need and so I feel like it's much more critical to achieve and we shouldn't be like blocked on it and there's other constraint also that that in my sense make makes sense to try to aim for faster finality sooner there's this other idea which is um having like this separate thread of development with like the the lean clients that's just like plugging at it on their own like separate from ACD. think it's also an interesting experiment because I've been like at Lindai in can I've also been like in Cambridge I met like some of the teams so in both events there's a lot of progress that's been achieved like the the result that they have on the postquantum cryptography is like super cool they already have these clients they are plugging away at like the networking layer like thinking really hard about yeah let's from scratch like what if we just started again today like what would happen and what would we do and I think this is actually like a very valuable data even to inform like the the more like short-term work that we that we do. Um yeah, so so I think it's kind of interesting.

Yeah, it it feels sometimes maybe in tension between certain things like you have the linch chain vision of Ethereum and then you have like different vision of Ethereums. I think we are trying as much as possible to like get the best of both worlds and I think both make sense to to coexist to to some extent. Um but yeah, it's a it's an active conversation. I hope that answers it. It was pretty long.

Yeah, cool. Thanks.

Yeah, thanks Barnaby. Awesome. Okay, we already got to the lean there and just Lee, go ahead.

Uh yeah, thanks for explanation and uh my question actually following your previous answer because you mentioned the like scalability and the UX UI improvement. Uh all of them I feel is very important and actually I feel like the UI improvement already make my life better now. uh but uh my my question is like ACM research team is kind of like you can say it's kind of like a small group of team so but uh the same need to be done it's quite looks quite a lot considering itself already a quite complex system and ecosystem also so how can you achieve that what's a specific uh way to to do so

yeah I think it depends on what exactly you're trying to fix. So for instance like if you want to do protocol changes it's fairly clear what needs to happen even if it's complicated it's kind of clear like you have to write an IP you have to get it tested you have to put it to ACD ACD has to schedule it in a fork and then it goes this this can take a very long time and and it can be frustrating but but it is how things get into like the protocol but then you have like other layers which are not blocked on ACD um blocked is maybe a bit strong like I don't mean to say that yeah it's like blocking but uh but yeah it can take time um and for instance like now I've been thinking about interrupt quite a bit more uh and here you can actually make changes u first for instance by proposing new protocols or new SDKs that either wallets or apps or infrastructure like can adopt so one of the things that we've been working on is this open intense framework like trying to make that a shelling point for people who want to integrate with some kind of interrupt solution that's more neutral than let's say the vendors that are out there and it's not something that we need to ask ACD's opinion on or need to schedule in a fork or anything. Um so actually we can yeah move move faster at that layer which which is nice. Um there's stuff actually in between. So there is right now like we're working on something called the fast confirmation rule.

So you have like this idea of finality which is when the validator say like everybody votes and you get like this um hard certificate that yeah the chain won't like revert what's what's been finalized. But actually before that happens you accumulate already like many many votes from many many validators in the in the process and and there's a paper that gives you like fairly uh precise guarantees in terms of if you've already seen like so many votes it's pretty likely that it will going to like it's not going to be reverted even if you have a very big adversary or the network has like some asynchrony properties actually know the network needs to be synchronous. for that to be valid. Um but so this confirmation is not something that we need to necessarily block on ECD but it is something that needs to be um implemented in the in the clients and if I remember correctly I think one of the fellows who's maybe in the in the room today has been working on the on the confirmation rule in in Lighthouse I believe and so yeah so that's something that is part of the client code but something that you yeah you can just um implement um outside of let's say the the regular fork schedule. So that can be also pretty nice because you can just ship it faster.

Okay, thank you. We get more questions come in. Go ahead.

Hi. Hi. Uh so um in case of small local changes which lead us to the future of Ethereum, what is priority now now? Is it um memory optimization like stateless clients or is it uh time optimization like you mentioned reducing time from 12 to six and what is more realistic and what are we closer to now?

Yeah. So actually we have like these three priorities. So scale one scale blobs and improve your interrupt they map almost one to one to like the current and following folks. So if everything goes well, fingers crossed, but I think so far so good. Uh in a month like we have Fusaka which is deployed on the network.

Fusaka gives you like a lot more blobs. So eight times more once all the blob forks happen which happens over like the course of a few months. So, so after that happens like you have let's say made very good progress on the scaling the blobs uh priority then the fork after that glamsterdam was kind of pitched as this is a scaling fork like we're going to use that to to propose like scaling L1 improvements so there's a few of them the big one is the headliner for the consens layer which is EPBS so that gives you like a different architecture of the slot where you have more time to execute transactions which means like you can have bigger blocks essentially. Um another one of the headliners which is the execution layer side one is block level access list that almost like um so every transaction like predeclares the the state accesses that they're doing and so the clients can optimize around that for instance like running stuff in parallel or like keeping the caches hot or stuff like this. And then a third thing that's kind of on the menu is doing like a bunch of repricing.

So as you know like when the EVM executes operations like you compute that in terms of like gas. So every operation has a cost but that cost depends on pretty much like the hardware that you're that you're using and the gas schedule has been like yeah drafted 10 years ago. And so since then there's been improvements. Some things got cheaper, some things got more expensive. And so now there's this effort to like um repric a lot of the up codes so that you can be closer to to the to the hardware that is being used and that allows you to like give um fairer pricing and also just optimize your resources um much better.

And so yeah, so with like this collection of EIPs, we should actually be able to scale the other one um quite a bit. And then my hope even though that's not uh decided and locked in is that HAR so the fork after glamdom will be the fork where we have six second slots where uh we can have the the short time the slot time from like 12 to to 6 second and so that fork should be more of a improving UX uh type of fork but before that we'll have like all of these interal protocols and app level or wallet that level fixes in place so we we can still make progress even before like the um the HR fork. Yeah. So I think that's pretty much what I have in mind.

Thank you very much.

Thank you guys. Please go ahead and raise your hands. Keep asking more questions. We have uh still a lot of time to go. Uh Barnaby doesn't get tired.

Um Shane Yeah.

had coffee before. Hey Barney, um I saw your Twitter post recently on the trillion dollar security project and I think in summary it's like you wouldn't be able to be able to lock up say a trillion dollars in a single smart contract which would be I mean that much trust and faith in set contract that's been audited and not likely to ever be hacked and whatnot. Um I'm guessing this is for like support maybe like traditional finance moving over to Ethereum for example. We want these guys to have faith in Ethereum. Uh that they can move large sums of money in and out of a contract on a daily basis.

Uh and I mean yes we have the metric of like 10 years of uptime things like that. But uh I'm guessing this huge project which has you know 10 different pillars to it uh is in service of that. I was curious if that is a correct assessment of why we're doing this.

Yeah. Yeah. Yeah. That's correct. Yeah.

And the project is um led by Frederick who is in the protocol security team and Joe Stark who is part of EF management. And so yeah the as you said like the idea is that you should feel comfortable like holding very large sums of money on chain. And so they went out and spoke to like many many institutions and not only institutions I think also just like uh interest groups of of users and and things like this to understand like what are the blockers for people to feel comfortable like putting a lot of assets on chain and they came up with like a list of different things. Um off the top of my head so I think the first one is actually UX. So, one thing you might remember is like there was this big hack recently like by bit where they lost I think $1.

5 billion and the reason was some sort of man-in-the-middle attack where somebody signed a message that was compromised by by an attacker and and there was a few places where you could have improved things by just having clear signing. So be a bit um more confident that when you're like pressing the button on your on your wallet like you're actually signing the message that you that you think you're signing. Um and so yeah, that's one of the initiative is to just like try and make sure that at this UX level um what you sign is is what you get or yeah like that you you're you're like very clear that you don't make these these types of of mistakes anymore. Um the next pillar if I remember correctly is I think developer experience. So for people to feel comfortable to put a lot of assets on chain you need the smart contracts to be secure which means that you need to be um able to write them properly and audit them properly as well.

So there's a lot of work that you can do there on the compilers on the formal verification. Um yeah just like improving the the level of quality of of smart contracts on on Ethereum. Um another aspect of it I think had to do with let's say more like the network uh level properties. So for instance the centralization of the validator set. So if the validator set is extremely centralized with like just a couple of parties that could collude and get the chain into like a bad spot for instance like finalizing something invalid where they steal all the money.

the chain can always like yeah full nodes can always detect such kinds of things and fork away and everything but it's still a bit messy and it can still be a bit of like a a thing you have at the back of your head where you're like I don't know if I would put like so much money on a on a platform that's controlled by just like a few people. Um so I think that's also part of the of the initiative like how do we how do we ensure that um yeah that that the chain remains decentralized. This is obviously something we all think about like not just them but I think it's good to to single it out as yeah one of the blockers that people have when they when they think about it and then more generally speaking yeah there's this also uh general problem of uptime. So how do we ensure that if goes down and this is very much like in the in the mandate of of a protocol security team and and other teams at at EF. Yeah, as you were speaking about the consensus layer to figure out whether or not like collusion could be an issue for um are these researchers um coming up with say like these three or four points is like this is potentially what could be the bigger issues the consensus layer are they working with the CL teams and having interop kind of whiteboard um hey in like this particular edge case this could happen yeah just curious um how they come up with these things.

You mean thinking about like um consensus layer issues? I mean

like why these like like Yeah. Why these particular like three or four things being the biggest? Yeah. And how do they come up with them as being like the potential worst edge cases?

I think because they just talk to people and that's that's what people told them they were the most concerned with. And yeah, pretty much f like probably stin up nodes and try to out and see if it really actually could happen because I mean I remember one of them was like oh for choice could get so bad to where like a lot of validators could get slashed um be obviously but I'm sure it's relatively difficult to um like force that happen I guess with testing.

I think I missed a few bits of your question. I'm sorry there was a bit of delay I think. Oh, I was saying um yeah with uh port choice for example if it is such a state to where we had worked on different chains then you could have different valers getting slash because they're proposing like valid blocks that was noted as like one of the things that they were concerned about with just curious um do they then go and try to test it out in like something like crytosis environment like can we actually force this to happen is this like a valid concern Yeah, I think there's a general thread around um these chaos test net. So try to put ourselves in like the worst possible conditions like a chain split or a network split or stuff like this and then try to recover from this. And one of the uh triggers or motivations is that this actually happened on on one of the test nets for PCRA and I think it was Oleski if I remember correctly.

Um but yeah, there was like um a bunch of clients that just didn't talk to one another anymore. Chain wasn't finalizing. It was it was a big mess and and recovering like the entire thing was actually very painful. And so they realize that, oh, if that happened like in in in reality, we should probably be prepared for these types of scenarios. And and I think now there's going to be like more of these um chaos nets where you try to make it as bad as possible and and and get get away from like the abyss.

Yeah,

there is.

Yeah. Yeah, that's um that's a nice PTSD you did there Babby mentioning the back test situation. Thanks. It was Yeah, it was fun.

Yeah, the front line. Yeah,

Nando uh has a question.

Hi, you've already mentioned the fast confirmation rule and also the back incident. [laughter] H I would like to maybe you know how would this fast confirmation rule would have worked with the pectra incident. The majority of the validator would have signed a wrong to a grown fork. So is would this fast confirmation rule make the chain finalize and break everything? Right.

Yeah. Yeah, that's a that's an interesting question. So, so the fast confirmation rule is like it's a local rule. So, it's only based on my node and my node can tell me if something was finalized or not as opposed to like full finality which is a certificate that everybody agrees upon or everybody who's online at least. And so yeah, let's say if I was running my node and there was like this chain split with validators voting on different sites, I would probably locally observe that my chain has like 60% of validators missing for instance.

And then I'm not sure the fast confirmation rule would actually allow you to confirm fast because you would say I've seen a bunch of votes. Uh but I've also seen like a lot of them missing and so I don't know that they might come later. And so one of the assumption of this fast confirmation rule is the network has to be synchronous and synchrony means if you haven't seen a message by like this amount of time um you assume that it was never sent in the in the first place. Uh but yeah, with a chain split, I think the fast confirmation would would not allow you to um or maybe it would actually. So yeah.

Yeah. So if you assume that it's synchronous and you're not getting like messages from 60% of these validators, uh you would assume that they never sent it in the first place and so that they're not going to like equivocate or or make you unconfirm the thing that you that you confirmed. Yeah, I'm not sure exactly. There's a bunch of math in that paper. You can just like plug in the parameters of how many people voted and your belief of like the size of an adversary and uh and it tells you whether you would confirm in that case or not.

It's possible that you that you would. Yeah, I think it's a it's a nice exercise actually to to try and work out.

I will try to to do it. I I had also another question that it is related to the sixc slots and the DVT. So h has any DVD client raised any concern about the the six second slot because maybe they will struggle to to propose new blocks or at the state.

Yeah. So I think the it was definitely raised at some point. So one thing that we are looking into is if you shorten like the slot time like how much time should you give to attestation versus aggregation to ensure that yeah nobody is left out and you still give enough time for the network. So what we've observed there was like a pretty nice like piece from Maya from rig on if research is yeah there are some attestations that are actually like would be coming late given the um the repartitioning that we would do for for six seconds. And so the game now is to try and ensure that we can just level up the quality of of of people on the network to to make sure that they actually get their test stations in time.

Why we feel somewhat confident doing this is we actually looked at who was sending stuff late and when there was like very clearly something that was very late, we always could find a reason which was like oh they misconfigured something or actually we found like this networking improvement that just makes things um yeah hop faster around the network. Um, so far I think we are confident that there isn't like a specific use case that would be oh sorry DVTs like you cannot attest because you'll be you'll be too slow for the for the network. I think it we seem like a a lot more testing on this anyways and nowadays like the testing and analysis resources are mostly looking at at Glamsterdam but um but yeah from the top of my head it wasn't actually DVTs themselves who were the the slowest participant on the on the network it was some staking provider that had this remote signing thing that was slower than it than it should be if I remember correctly. But um but yeah, we have like this data set of validators labeled by which pools they belong to. So we can also know who is like a DVT and and who would be maybe slower in that case.

But it didn't come up in the in the data. So I I think that's not an issue.

Thank you. Thank you for that answer.

Okay. Thank you for diving into that and more questions coming. Awesome. Thank you so much guys.

[laughter]

Yeah, sorry. Yeah, it's a network.

Not sure if it's just me, but we can't hear you properly. Yeah. Yeah. Yeah. Uh maybe try it on camera.

Yeah. Deitri, your voice is uh cutting off completely. You might want to you might want to leave and join again.

Yeah. Sorry about that. Um it's when you are running the super node on the same network as your gypsy call, right? Sorry.

I think we just still hear every other word.

Maybe just text the question. I guess

y

Yeah, please write it into comments here. Post it. We can read it or in the Discord chat. And meanwhile, please raise your hand for more questions. Um, normally I get uh more to chat with these guests, but I'm glad you have so many so many questions for Barnaby.

So, so keep it coming, Shane.

Yeah, I understand. And like we said, if we're going to get pure ass, so that's blobs. And then Glam Amsterdam, we'll get with EPBS and balls. Then we'll get some pretty good UX benefits with six second slots following. I'm just curious like if anywhere sensor super resistance it's like fossil kind of falls in and where that fall in.

Yeah, actually there's going to be like a fairly important debate I guess tomorrow on ACDC which is uh do we actively schedule for sale for being included in Gladam or do we not and then I guess the implication would be that it would go in HAR. My personal preference is actually to schedule for eight star along with six second slot. I think it would be a pretty good combo because fossil has already been fairly well tested and implemented. So I think we're pretty clear on how it works at this point. Six second slot is conceptually not very difficult even if if it's actually pretty difficult to like implement right because of like the transition from 12 to to six.

Um but yeah, if we did schedule for sale for like Amsterdam, the expectation is that it would add at least two more months of of delay to the fork. Um I think it might be an underestimation to be honest. Like EPBS is such a big chunk and is also not that small either. I kind of feel like we will maybe bite off more than we can chew with this and and I think it's much better for us to have a good fork cadence like ship things regularly like the more you delay the fork the the the later you can enjoy the benefits of what the the fork brings. So I think EPBS block level access list like these are things that can give us very tangible benefits very quickly.

So I think it's best to just like ship them um and then wait until eight star for for fossil and six second slots. That would be my my personal preference.

Got it. So we'll still prioritize it and very likely and the two next for works and yeah very good points on whether or not should go into either Glamsterdam or HR it yeah both ways. Um like with EPBS we're adding in new committee the PTC and then also with Fossil you would add in a new committee and my understanding is if you were to do both in the same upgrade you would design it such to where they would be the same committee that would solve both situations. think that the condent like you're saying not just sound like it would take longer to implement by a couple months um actually agreeing on the proper spec of how you would do both would take a lot of back and forth and probably be the thing that takes the most actual time and I do have a feeling that something like sixcond slots is going to be lighter on the CL so then implementing something a little bit heavier like fossil would give us the lelay for that so that just makes sense we'll see what happens tomorrow then Okay. Very well.

Uh we got a question from Demetrius in Discord. So let me uh uh read that quickly. Is there a strategy to maintain the validators decentralized while few entities eg financial institutions hold a very large percentage of stake? Is there an actual danger that uh they veto some upcoming update that harms their interests? Yeah, that's a topic that I thought about a lot with other people as well.

I think there's a couple of questions there that are interesting to think about. So, one of them is the role of a validator. So, today they do a lot of things like they attest, they produce blocks, they will also do fossil lists maybe in the future. Um, one of the things that I've been thinking about is this idea of like rainbow staking where you can try to essentially have like a division of labor so that you just assign the functions to the people who can best provide them. Um, and maybe in that sense you actually really only need like a very decentralized set of people to do fossil because they are the ones who inject like this chain neutrality into into the ledger which is important.

uh you need a fairly decentralized set of attesters because yeah people voting on the chain like that's that's important um and then you might be fine with like a more centralized set of block proposers or builders for instance um there's limits to that like I don't want to say everything flies but um but that's let's say one possible strategy the reason why that might be palatable is because one of the benefits you get from like a smaller validator set is that you can get faster finality and there's actually there's a cost to not having faster finality and I think on the trade-off curve so far like we are very far into eating a lot of the cost of not having faster finity but not getting so much benefit from having like such a large validator set either. So I think it's it's interesting to to revisit that and there's also the other perspective which is that the validator set cannot really impose their view of a network by themselves. Um a full node can always like desend and exit and just restart. It's easier said than done obviously because it's yeah it takes a lot of work to like do this. But um but yeah I think that's one thing.

The other thing is that even though that's true that like you can always verify the chain even if the validators are like colluding to try to deceive you about the state of the chain. I think it is true that yeah if there's a few validators who are very well financialized very close to like financial institutions let's say digital asset treasuries and staked ETFs and and this type of stuff it can change like the politics or the political economy of of the network as a whole and it's not necessarily a bad thing in the sense that these are people who use the network and who are operators and who maintain it the question is like are their incentive like suffific efficiently aligned with just network stability and network neutrality and network yeah permanence and innovation and things like this. So if you have like a validator set that's just like extremely conservative and doesn't want to do anything that can be an issue. If you have a validator set that wants to do things that are completely opposite to like what the broader community wants that can also be an issue. Um yeah it's tricky.

I still think we should be aiming for a smaller viator set while keeping the entry as permissionless as possible. I think that's a good way of keeping the the system in check. Um you can have fewer entities but as long as they can be replaced um I think that might be a good um middle point. Thank you for the answer there. Yeah, that's a that's a tough question uh with the thank you for handling that.

Awesome. Okay, we get last five minutes. So maybe if we have one quick question from the audience, anyone wants to take the opportunity. That was quick. Sherry, go ahead.

Uh yeah. Uh so you mentioned that shortest plot times will be something that one of the upcoming beacon chain folks will be uh like we we'll plan for it. Uh I'm wondering and that's something that was proposed in the lean consensus efforts. I'm wondering if more stuff from the lean consensus efforts say PQ signatures uh and and some and some other stuff from the lean uh lean stuff will that be coming towards beacon chain folks uh is that is that something uh that we thinking? Uh yeah.

Yeah. So yeah actually when we say shorter times like there's different I guess graduations it's like it depends how short you you want them to be. So link consens I think the target was like 4 second slots and they the idea is this is like very small and it's good to to get to that level. What we're proposing as like an iterative change is 6 seconds slot. I personally believe that we can go even shorter than than four seconds.

And we we currently have like some work done by the consensus team on on decoupling the block time from the attestations and the finality accumulation, let's say. And that would allow you to commit blocks pretty fast while building up like the the finality on on top of it. So like decoupling these two things which is currently like a blocker to to get really really short slots. So so yeah in a sense some of the goals that let's say we all have a goal of shortening the slot time like the question is how do you do that and and when um I personally think you'd be good to do like one iterative step already as soon as possible to get to six seconds. I think you would show the willingness to to do this sort of stuff.

you would also actually have like very tangible improvements. You would just have more responsibility when you when you transact. ME markets would become uh a bit better. Um but yeah, long run I also think we should be aiming for even shorter than 4 seconds. I think the number that was flying around recently was two seconds as a sweet spot between long enough that we can allow broad network participation but also shorter now that we get like pretty pretty good benefits.

So yeah, I think that's that could be a nice a nice goal.

Thank you so much Barnaby. That's interesting. I mean the bandwidth there is stuff and like even two seconds I mean it sounds sounds uh like we need to we need to optimize a lot to get there. Yeah, thank you so much. Uh we got we got the last few minutes and before we finish I wanted to uh also ask one more quick question about uh something um that you or learned along the year some advice to uh to the fellows here people who just sort of started their journey now and uh now finishing the fellowship they are um they're going to be more independent.

So what is what is something that they should uh uh they should know? Something that maybe you wish you knew at the time when you were uh starting your journey? Any any advice for the followers?

Um yeah, I mean it's probably I think maybe more on like a personal level. I feel like the crypto space is moves extremely fast. Like when you open Twitter, there's a lot of different conversations. like every week it's a different thing that people are are chasing after. The main thing where I got burnt is sometimes feeling like oh this is a sprint and I need to run after like many different things.

I think it's actually more interesting to build progressively like take time to really go deep on one of the protocol components like the protocol as a whole is very large and there's many different parts to it. become an expert on like one of them and then just like build out your your domain expertise from there just like start to to radiate further and further. Um it doesn't mean that you should be slow. I think it's still good that you think about the urgency to ship big things and to improve the protocol and to yeah just generally speaking like a lot of people now depend on Ethereum. A lot of users want changes, features, etc.

So, I think it's important to realize that we're in a bit of a special position to to achieve these things that have like major impact. Um, so the urgency is important, but at the same time, personally, taking the time to u yeah, just understand things well, carve your niche, and then expand from there. Don't try to like hop on so many different things all at once. Yeah. Yeah, especially today with uh the protocol growing so much, it's more about becoming expert in the various areas and collaborating because it's just uh it's just so big.

You can I think like when when we had the road map of the boxes, I always say like you can spend your life in one of those boxes basically. I mean it's a [snorts] uh it's a big protocol now and we are exactly at one hour so I think we're up here. So yeah, thank you so much for being with us today Barnaby. Thank you so much for all your insightful answers, all your advice, all your uh knowledge that you shared with us today.

Thank you.

And uh yeah. Yeah, it was great. And uh yeah, thank you so much everyone for joining for our last AMA office hours. So this was the the very end of our guests uh during the EPF and uh in the next office hours we will have uh the presentations from the follows. We will hear from you uh guys for a for a change to uh to see your final project presentations.

So, I look forward to that next week and then I'll see you all in uh Buenosirus. So, yeah, see you next week and thank you so much again everyone. Um, it was great having you for one more AMA. So,

bye.

Bye-bye and have a great day.

Thank you guys.

Bye.

Thank you so much. See you there.

Byebye. All