Ethereum Cat Herders Beacon chain proposals, 25 Jul 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP #114: EIP-7045: Increase max attestation inclusion slot with DannyR #staking #validator

Description

Resources:
-----------------
EIP-7045 - https://eips.ethereum.org/EIPS/eip-7045

Slides - https://docs.google.com/presentation/d/1oWaRir0XjcWOYGFo9rjDnWrudv_mvzBQ0uVxDQUpk_Q/edit?usp=sharing

PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F

Dencun - https://www.youtube.com/playlist?list=PL4cwHXAawZxpnKFDl1KzGOKqwux5JaLlv

Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2

YT Shorts1: https://youtube.com/shorts/KlZgbFtcdIQ
Clip: https://youtu.be/s9v2SObVY7I
Full video: https://youtu.be/qu65E64Jtts

Follow at Twitter
--------------------------
dannyryan @dannyryan | Pooja Ranjan @poojaranjan19

Topics covered
-------------------------
0:25 - Skip Intro
1:38 - Meet Danny Ryan
2:52 - Blocks and Attestation
4:30 - Block tree
4:45 - Forkchoice rule: LMD-GHOST and FFG
5:53 - And potential re-orgs
6:15 - But not past FFG finalized checkpoints
7:00 - Attestation inclusion window
7:58 - Inclusion window in spec
9:21 - Counterfactual inclusion window
10:54 - EIP-7045: TL;DR
12:42 - Why EIP 7045?
15:18 - A Confirmation rule for Ethereum
20:17 - What is changing since the original beacon chain
22:15 - Single Slot Finality
23:50 - Fork time stamp
25:45 - Attestation data
26:55 - Consensus specs repo
28:52 - How to follow client implementation
30:20 - Consensus Upgrade specs repo
33:40 - Cross Layer EIP
35:50 - Security consideration
37:30 - Thoughts on EIP documentation process
40:50 - Discussion to link for the CL proposal
45:50 - Sequential EIP number allocation
46:47 - A message to the validators community

A

Then con upgrade is including two eips for consensus: client Improvement as a validator general Enthusiast. If you would like to follow, the upcoming changes to the straight transition function continue listening.

A

Hey everyone: this is Peep and Eep episode, 114 ambuja ranjan in this tenkun special episode. We are going to be talking about EIP 7045 increase, Max attestation, inclusion slot documented in May 2023 The Proposal is currently in draft status to talk about the proposal and explain what changes will it bring to the ethereum main net? We are joined by a very special guest whom you must have seen in Dev meetings and events talking about ethereum consensus layer.

A

Let me welcome one of the researchers all core Dev consensus meeting coordinator and the author of The Proposal Danny Ryan welcome back Tani.

B

Hey thanks for having me for.

A

Our new followers uh Tani has been generously taking our time to educate the community about the upcoming changes. We have had him in the past. Talking about EAP 2982 Altair, the first beacon chain upgrade so on so forth. I'm so excited to have him back on the show to talk about the latest tenkun proposal, but before we get there, I request Johnny to briefly introduce yourself and share your journey in the ethereum ecosystem. Yeah.

B

um So my name is Annie Ryan I work with the ethereum foundation on the research team, so I do some research I. Do a lot of I've done a lot of specification writing over the many years and I do a moderate amount of coordination, uh mainly with the consensus layer side of things, but just kind of across the development effort in upgrading ethereum, Amanda, 2017, I decided ethereum must be my job, so I gave myself a year to contribute to open source things and just figure out ways to get involved.

B

I got heavily involved in the stake efforts during that year. Thinking it was imminent, sorry, helping out there and since then have worked on all sorts of things related to proof of stake related to scaling related to ethereum security. It's been a fun Journey.

A

Since then, awesome very well. Thank you so much for this brief introduction. I'm aware that we have got a presentation for today's proposal so without further Ado, let's peep in great.

B

So eip7045 for Peep and Heap I did give a brief intro. Those are my handles djr2 on a lot of platforms. Danny Ryan on a few like Twitter, like I, said research, specs, coordination, all sorts of things and helping ethereum, mainnet cool, so I I want to kind of start with some background, make sure we're. On the same page, on the consensus layer, we have two primary data structures. We have blocks. We have that stations if you're familiar with all with blockchains. That's what a block. That's?

B

What blocks are when we're talking about them in the consensus layer? They form a chain, they reference, each other. They have all sorts of data transactions, all sorts of good stuff. We also have this very important data structure, called attestations or sometimes called votes and votes or attestations every time, there's a block.

B

So every slot every unit of time on the consensus of the ethereum mistake chain there, one proposer produces a block, but many validators are invited to a test to say what do they think the head of the chain is to kind of throw their weight into it. So they make all these little messages the circles and vote for a given slot. What they think the head of the chain is. These votes can be included in subsequent blocks note.

B

This can be confusing if you're not used to blockchain diagrams blocks reference, their parent, so the arrow points backwards. Time is actually moving from left to right. So these are subsequent blocks. These are children or descendant blocks of what was voted on so these little circles. Here these attestations can be included in subsequent blocks. That really forms the core of like the Consensus These, two data structures, they're so critical. You know the block proposal comes up and says this is these? Are the changes?

B

These are the things that are going to happen during the slot and then other validators come in and say: yep I saw those that looks valid. That looks good, I'm happy with that. Importantly, we often talk about blockchains, obviously, but we actually have a blocked tree, so we can have any number of like four Kings, so we can have conflicting proposals. So forget a given block, you might have two potential descendants and so what we take this block tree and we actually try to form a blockchain, the one single canonical history.

B

So given a block tree any of these, the green, the purple or the blue, my might be seen as the canonical blockchain, depending on your view, the algorithm Etc, and so what we use in ethereum steak are. These combination of two algorithms, one called lmd ghost and one called fog, album, digos's latest message: driven greedy, heaviest observed, subtree and F of G is uh the friendly finale Gadget, so lmd, ghost kind of deals with the tip of the chain and FFG deals with finalizing checkpoints forever in history.

B

And so when we look at l d ghosts, this is called the port Choice Fork, meaning uh which branch in this tree is going to be canonical. We we use a simple algorithm that takes these attestations and assigns each attestation kind of assigns weight recursively to the branch, and so really we sum up these attestation weights and we get to a chain tip so right now this one in the middle has 17 total at the tip, so that tip recursively defines a whole chain. That's our canonical chain.

B

The thing about lmd ghost is that it can reord. So if you get new information, you get new blocks, you get new attestations. All of a sudden. You can find a chain tip that has any of your weight, and so what you thought was embedded in the chain. What you thought were user transactions that were going to be confirmed might actually change. Your view can change, and so anything in this kind of lmd tip is subject to potential change. The nice thing is that we can finalize segments.

B

We can finalize these checkpoints at some depth in a chain, and once we finalize we can we don't have to think about the rest. We know that that will never change and so the rest of these things that are Divergent with the finality. Actually, this block should be finalized on this one I apologize, pretend it says, finalized right here. Actually, let me fix it back in Action. So if we finalize this anything diverge any chain that doesn't include this finality is no longer fair game, and so we don't.

B

We can't have reorgs past this, this depth, which is really nice, and so that's the difference between kind of FFG and lmd lmz. How do I pass finality figure out? What the chain tip is? How do I and then F of G is like what are these like fully locked in segments that have full security?

B

Another important part about the mechanism of these block synaptic stations is attestations, can't be included forever. There's a this inclusion window so at slot in attestations happen and from slot n, plus one to n plus 32. Those attestations can be included on chain normally in mainnet, like most of the things that happen in the end just get included in in plus one, but in very exceptional scenarios you can have these attestations filter in for up to 32 slots.

B

32 slots is how long an each Puck is, which is kind of like a large unit of work in in the ethereum proof of a stake chain, and this is this- is rolling so like this. Adaptations for slot in can be included from to n plus 32 attestations for n plus one can be included all the way up to n plus 33.. So you have this kind of rolling window for a given block for given slot when agitation can be included, and that's really what we're looking at in 1745 is modifying this window.

B

So this in the proof, mistake spec, which is a bunch of python code that rigorously defines uh the spec we can see in the state transition. Attestations that are included on chain are verified via this function. Processation- and we look right here- we can see the kind of the window, the Min and the max, so managerstation inclusion delay is one so the agitation slot plus one you know it can be all the way up to the association slot plus slots for Epoch, which is that 32. and so that one one line defines this window.

B

This window was inside, decided before the phase zero launch. So before kind of the Proto Beacon chain got into production in 2020, it was decided to put this window, as you know, most of the most of the spec at that point, and it was decided because this window seemed fair. So for any slot that you created an adaptation in you get 32 Slots of inclusion of potential inclusion.

B

You know so it doesn't matter if you're at the start of an Epoch the end of an Epoch, you always get exactly 32 slots that you of this Raw rolling window where your attestation can be included. So it's just kind of like you, don't seems aesthetically pleasing that you didn't have asymmetries between the beginning and end of the epoch, but not really a strong security argument for why this was the case, not an argument. We didn't find an argument against, but it was more just like okay. That seems right. That seems. Okay.

B

There was this counterfactual inclusion window that we did discuss at the time, essentially to. If attestation is created in Epoch X, you could include an attestation in all slots remaining in Epoch, X and all slots in Epoch, X plus one.

B

This is this was seen as less Fair, because if you were assigned to a slot at the start of epoch X you could get almost 64 slots. You could Olive X and all of X plus one for inclusion, whereas if you're assigned to a slot at the end of epoch, X you could, you could get more like 3233 slots, um because you, the end of epoch, X, there's almost no time remaining, and then you only have X plus one.

B

So you get this kind of asymmetry between like where you were assigned in Epoch on like how long it takes to get your opposition included. And importantly, if your accusations included on chain, you get rewarded positively. If you don't, then you can get a penalty, and so we were kind of like ah it seems unfair. It's a weird asymmetry! Let's not go that path, but there wasn't like a strong reason.

B

Besides this kind of aesthetic fairness, reason and note when we think about it today, we realize that, like fairness, matters within an Epoch, but it really matters over like many many repeated epochs, because you're, if you're a validator, you're constantly doing this role over and over and over again. So even if there's an asymmetry between within one Epoch, you play this game over the course of the day, of course, a week course of months, which you do as a validator. It's fair over many repeated executions. So the fairness argument wasn't even that strong.

B

So that was the alternative we considered at the time and eip7045 tldr. You learn nothing! It's swapping from the original inclusion window to this alternative so, and there are good reasons to do so that we learned since then so this window of the slots per Epoch to this window, any slot within X and X, plus one where the slot is greater than the attestation and again this is free, EIP 7045. It has this bound from slot, plus one to slot plus 32.. This is the whole change of the EIP next slide it doesn't.

B

It just doesn't have the upper bound note that this line two lines above, which was there in both make sure that the the attestation is from either the previous or the current Epoch, so we kind of get that X and X, plus one bound already, so we just reduce this condition.

B

We make sure that it's at least older than the slot is created in so we get plus one um and then we're bound to both epochs from this previous line, it's probably about as simple of an EIP about as simple of a change as you can make to the state transition function. You know in terms of testing and the consensus test.

B

This was you know, conditionally modifying a test at this boundary and adding like probably two or three tests, to really cover some of the edge cases here and note that this is the state transition function, there's also the P2P gossip conditions. You know upon what condition is a node allowed to forward these messages to its peers? um It also had this the slot bound the same 32 slot bound.

B

We also have extended that in the PDP gospel condition, so essentially this condition mirrored, but when, when you're deciding to forward a message to your peers, so that's the what that's what's going on, but I didn't give you much of a why. So, as we discussed at the beginning, fmg finality confirms things every approximately two epochs and Epoch is 32 slots. Slots are 12 seconds, so an Epoch is 6.4 minutes.

B

So we're talking about finalizing and really confirming and like being able to make decisions about, what's included in the canonical chain, every like 13 minutes almost um and that's that's- to get things with that. Maximum security, which is great the beacon chain, is very secure. There's a lot of crypto economic capital validating it, and so we get like a very high security threshold on these finalized tips, but until then we don't have much Assurance as to what's going to go into the chain and so before finality.

B

We have this lmd ghost thing and, as we pointed out, it could potentially reorder and lmd ghost analysis and potential confirmation rules and I'll get into that. It's been kind of elusive. You know it's been actually kind of a major pain point in the analysis and the understanding and the extension of this proof of State protocol. You know, essentially under what conditions am I, confident that this block tree is not going to reorg right other than not taking into account those finalized checkpoints.

B

You know, can I just looking at this block tree figure out using lmd ghosts, what's not going to reorg and that that question has been done. We've been beating our heads against the wall on that question for a long time, and so, let's, let's look a bit more when I say confirmation rule you know. Obviously the confirmation rule of FFG finality is like maximum security. That's a good confirmation rule. It just takes a long time, but the confirmation for lmd ghosts is.

B

Can we add additional assumptions that if they hold blocks and lmd ghosts cannot be rewarded, so such assumptions might be synchrony, you know, FFG is asynchronously safe, so I can get messages from five minutes ago and I can I know when I when I finalize something that I'm safe. Whereas can we relax that can we say under normal midnight conditions, I'm very confident, I get all my messages within a slot or within two slots. You know if I make that assumption.

B

As long as that assumption holds, can I confirm things you know, can I make stronger assumptions about the honesty of the set. Can I make our construct rules that require really high unlinedness. You know like you, don't you only really need two-thirds online to to finalize something in F of G, but what? If, under normal main technicians, we have like 95 online all the time? What if we assume we had greater than 90 online? Can we confirm something quicker?

B

And so, when we're, when the past few years we've been seeking in lmd goes confirmation rule um and playing with, can we make more assumptions to try to get these? These confirmations faster confirmations. So fortunately, at the beginning of the spring this year, these five people locked themselves in a room and didn't come out until they figured out a confirmation rule.

B

uh So this is a people from the ethereum foundation at the chef, Francesco, Luca, uh very strong consensus, researchers um and then a couple of people from consensus, Roberto and Cheney, who are very strong consensus, researchers and foreign verification engineers, and they did it. They beat their heads against the wall until they came up with a confirmation rule that works on ethereum mainnet for Ellen degos, which is extremely exciting. I'm not going to get deep into that confirmation rule.

B

But if you would like to dig a bit deeper, here's the E3 search post, the QR code, that kind of explains it from a high level and links to the deeper paper and here's an explainer blog post. That adicha wrote that has some really nice diagrams and can kind of walk you through how it works out. You know rigorous, but less of that kind of academic paper approach check it out if you're interested.

B

So the tldr on the confirmation rule is that in normal magnetic conditions and reasonable assumptions, we can confirm blocks in three to four slots, which is really really exciting. You know that's I can get some semblance, some understanding of. If something's going to become canonical on the order of like 30 seconds to a minute it does to get those fast confirmations. You make a one slot synchrony assumption and to get those fast confirmations for it to really be kind of like functional.

B

We want to see like greater than 995 blocks and attestations, so missing blocks and missing. Amputations reduce the efficacy, the confirmation, Rule and importantly, all of these values can be tuned. You know so, if you're not willing to make the one slot synchrony assumption, you can make a two slot security assumption. If you're not willing to make certain online edits or honesty, assumptions can change those that's going to make it take longer, but it's going to be a stronger confirmation, so you know maybe you're on the order of five minutes.

B

You know you're on three minutes instead of that 30 second window. Very importantly, the security analysis of this confirmation rule requires the alternative attestation inclusion window that we've been discussing and the intuition there is essentially you need to be able to. So we can do FFG confirmations all the way through the end of the next Epoch after adaptation, and if we observe something on the P2P, we want to have stronger assurance that it can actually make it on chain, and so that's kind of the intuition here.

B

But again, if you want to dig deeper into it, please check out these posts, but we need that alternative inclusion window, thus eip-7045, because erp7485 essentially enables this confirmation rule this long sought after conformational, it's extremely exciting for ux. It gives applications different kind of decision points.

B

So if I have a really high value application, maybe I'm like an exchange and I'm processing deposits of like a million or 10 million dollars, I probably am going to use FFG finality, but if I'm that same exchange and I'm processing a 50 deposit I can then use this fast confirmation rule to give enable like a much higher uh better ux.

B

For my users, which is really cool right, like I, now have like a spectrum of Confirmation and security and assumption that I'm that I can take as a you know, as an application, you know, and even with rationing up those assumptions for the confirmation, all the synchrony assumption. The honesty assumption I can also have good gradations of that as well.

B

So you know that daps, all sorts of other things and wallets anything that kind of like shows you if things are confirmed and allows you to do things with respect to Capital, with respect to assets or respect to kind of anything. They now have this alternative, and so we're really excited the specification of the confirmation rule is nearly complete. There are some proof of concept implementations.

B

We're really excited to have the net go, live to enable the confirmation, Rule and these specs to be finished such that we can start knocking on some doors and say Hey, give it a shot. You know this has these different security properties from FFG. This could enable better ux for certain types of users and applications yeah. That's it! It's swapping that window. It's a one-line change in the state transition function, it's motivated by having passed a better confirmation rule which was down by those researchers in the spring. So you know it's kind of.

B

um As of now it's going to go into the neb, obviously nothing's in mainnet, until it's fully done fully tested and actually deployed, but it's about as simple as it can get, and that was really exciting questions.

A

Awesome, it was a wonderful presentation, I mean explaining Tech is challenging, but you did a great job representing the blogs and it's cleaning the concept. I hope it will be helpful for many others to understand what we are trying to do over here. I have a few questions for you. That I would like to touch on. First, uh like I, want to understand the main challenges if they were at the time of beginning of the beacon chain, because I'm assuming this is what we are doing with 7045 is improving the original Beacon chain. Yeah.

B

So, a lot of time, a lot of thought: a lot of research kind of went into designing the original Beacon chain, but until the system got live, there were unknowns right. So certain like ux pain, points, certain security, trade-offs and different things like that that, since a lot of the original designs which people working on design since, like 2014 2015 early research, really the full Beacon chain and thought like around how to construct it was started in 2018. It was deployed in 2020. It's now, 2023., we've learned a lot right. This is like.

B

Probably this is the highest value proof of stake chain in existence ever, and so there is just a lot of learning to be done, and so you know this idea of fast confirmations wasn't even really something we were talking about five years ago, whereas it's become like a very important ux point, so it's then become like a certain research Direction. So then, all of a sudden, you have this live system and it realized.

B

Okay, if you make this little tweak, it can make it better, and so we certainly there are a number of proposals from small to large like this, that are researched and debated and will be for the next few years, really because this we've realized how to refine this live system. Obviously like changing a live. Blockchain is like no joke, uh both from a technical standpoint and a social standpoint. You know changing the promises that have been made and the expectations and understanding of the system is a big deal and a challenge.

B

Fortunately, for this kind of thing, this is purely a security Improvement. It does not affect the ux really of anyone. If anything, it makes it slightly better to be a validator, because your attestations can be included for longer Windows, sometimes but yeah. It's um a lot of us worked on this thing for many years. We did our best, and uh this there's still a little bit of work to do, and some refinement to do great.

A

Thank you. If I heard about single slot confirmation of the blocks on the consensus layer, is it something like a proposal 1745? Is it something moving in that direction or those are separate.

B

Yeah so there's a research Direction called single slot finality. Essentially right now we have multi epoconality. It takes a long time to get all the validators to vote and agree on something single slot.

B

Finality is a research direction to try to figure out ways to get all of the elevators to be able to vote every slot either by having much more efficient networking constructions, more efficient consensus, uh cryptographic, instructions, reducing various types of load, so that we can process more votes in a single slot, and this is a really nice ux Improvement if it ever goes through, because instead of getting these lmd ghost confirmations, which can happen on the order of a few slots, you can get full crypto economic confirmations on the order of a slot.

B

This is so this, like kind of dips, our toe in the ux Direction having a better ux, but it doesn't fully make the deeper changes to the protocol that single slot finality or ssf would bring and require to get this kind of full crypto economic confirmations, but similar work streams. Essentially, like what methods and techniques do we have to get faster and secure confirmations, uh but this is like the the really easy tweak that gives us something rather than a much deeper change. Something.

A

That can help us for like very less code, but in.

A

Proposal and I came across something called specification constant. It seems that the value is not added so I'm curious, like is it still in a discussion or how are we going to decide a constant value for that? So.

B

I think the only constant that's in this EIP is the fork time stamp and that we would just essentially any whether explicit or implicit for any query. Ip that goes to layer one. You have to have kind of the coordination point, and so the fork time stamp would be for the fork as a whole, and it would turn this feature on, um and that would be in the event that it goes to mainnet, which it looks like it's going to and we are kind of towards the end of forking the public test.

B

Nets then uh core devs would decide on like when is the proper time to Fork the test net. So there's a pork support maintenance and to fulfill this constant, so I think that's the only configuration value that's in this one, depending on the specs. Sometimes we have configuration values that we're unsure of like, for example, four for four, the amount of like blobs that can be included and in that, when we're unsure we're doing a lot of like Testing, Research pen and paper running mainnet experiments that kind of stuff.

B

But this one doesn't really require that.

A

But it's good to know, but this is something different that I have never observed for any Corey IP, so it caught my attention like in specification section mention of the uh timestamp. Oh.

B

Interesting I I've seen that maybe I feel like in 2017 2018. That was like fourth time stand or Fork block was included more and so I, maybe I'm just like uh old-timer at this point and and using that it's not really that important. Essentially, it just says at Point a that time time in point a b like we will not. This feature will not be enabled and then at some point that we have to decide the feature will be enabled.

A

Right, I'm, not 100, confident perhaps uh this value might have been in the meta file, meta EIP, which was at the time for upgrade considered. But since we are not following meta EAP anymore and.

B

A

Separately, so yeah, but good good thing. No problem I found another uh piece of information which suggests that uh the spec removes inclusion, delay I'm assuming it's redundant. Is that the reason yes.

B

When I was looking at some of the codes, this is the this is the validation conditions, First We Take the adaptations data and we make sure that the epoch is in the previous or the current.

B

So that really means like if the attestation was created in Epoch X, is it X or X, plus one, and so that puts a maximum bound already, because once you enter X plus two, you can no longer include this thing on chain, and so, but previously we had a tighter bound on the slot because of this plus 32 right here, and so because we already get the epoch bound, which we want to be the maximum bound.

B

We really just have to remove the upper bound on the slot, and so by removing the upper bound on the slot validation. We fall back to the epoch, validation, which becomes our upper bound and so yeah. If I would have put like the slot and actually calculated the slot dynamically of of what the current Epoch is, that would have worked, but it just would have been redundant with this condition right here already.

A

That makes a lot of sense. I have a few more questions with respect to Specs I'm curious. If the latest CL specs include eip7045 and if so, what is the version number of that yeah.

B

So it consensus back cerebral and we have releases and releases only happen when things actually go to Mainland, so the latest release is v130, which is actually the mainnet release for capella, which was the last cardboard. But if you actually look at all of the releases we have pre-releases and so v140, and you know all these Alpha versions beta versions. These are not actually going to mainnet, but they're test versions, pre-releases that are on testnet and for for discussion and Analysis.

B

And so, as you can see here, the name of this spec was consensus, specs Tim's Vision, because he wanted to use consensus, layer, eips- and here we finally are consensus layer, your IPS at this point, the deneb spec, which is the name of the next hard Fork when it only had four April 4 in it. For initial testing. We've added these three eips to this pre-release, so 4788, 70, 45 and uh 7044, which 4788 those aren't too relevant. But these are the uh what those Yankees are. So it is in the deneb pre-release.

B

So it is in what everyone's working on for development for geneb, like I've, said multiple times uh until this is a v140, the official release and and think or you know, the final release and things have gone to mainnet. uh Will we, you know say that it's finally economically kind of embedded in there, but one for v.1.4.0 when it comes, will be the the kind of the final version for denab about.

A

It yeah that's helpful, because the CL has always been a leader here for this kind of experimentation and getting the specs added for testing purposes. I think this is a useful and new information for people on the yield side. I have a similar question on on the same topic here like for El. We generally look for the eip's implementation. The client implementation are we aware, like now does that is added in pre-release pack? How do we know that which our clients have implemented? This proposal.

B

Great question I know that it's being tracked, I, don't know exactly where it's being tracked right now, it has been verbally agreed upon in the consensus layer calls and in the execution layer calls that not the current devnet, which is only for it for four, but the subsequent devnet, which I believe is devnet H, will be full featured, which will include the additional eips on both sides, and so because of that we have a strong signal that the consensus layer teams are working to that full feature set.

B

This latest release and we'll be ready for devnet8 I know that some of the devops folks that help run the devnets do have documents tracking Readiness I, don't know if they have a document for devnet 8. Yet up, but it's being tracked, we um it's a good question, though, because I know on the execution layer side uh there's been a bit more rigor in tracking kind of Readiness and different tables and stuff. It's something definitely consider as we approach to node. If we want to do the same thing.

A

Yeah I think that would be helpful, especially for people who are not so very technical, but they want to keep a close uh track of how we are making progress. I'm, not sure if this is a practice for consensus layer as well, but I'm just curious. So do you guys consider having a folder for every upgrade, so other people can just go click to that folder and we'll get to know about what happened. What went in inside, like that yeah.

B

Let me give you a view, so here's here are the consensus letter specs repo. uh We can go look at the main readme. The first thing that happens in the main remains are the stable investigations, which generally are like the forks, the hardportes, so we pay zero irrelevant documents. We have Altair Bellatrix note that these after phase zero their names of stars and they go in alphabetical order. Then we have capella. These are all the things that are on Main net and then we have in development specifications.

B

So denab is that next Fork, so people can check out all of the different spec changes here and then we have a lot of different like feature Forks. Our feature just independent features that people are experimenting with. So if you actually look at the specs folder on this repo, we can see. First and foremost, these are the big upgrades, and so we can go to teneb and we can look at all the different files related to the NAB.

B

If we go to the beacon chain, the nice thing is everything's annotated by the EIP, so I want to see the 4844 changes. I can just search for it before and I can see new into NAB. You know these these little annotations. You know this. This was modified into NAB, whereas this feature of this data structure was added new into node. Similarly, you know 745 I can hone in on annotated.

B

You know what are the exact changes here, so that's how those are organized and then, if you are looking for the features that are not inflated for hard Fork but are currently under kind of people are working on doing some r d on we can go into here and we can see you know eip6110, which is the potential feature to change uh the way the deposit flows work, to make it more uh secure or 7002, which is to add execution layer, triggerable exits.

B

We get this nice kind of subfolder that you know if you're not involved in r d, you don't really go check it out, but if you do want to see like some of the the features that people are working on, it's in this underscore features uh folder, but the main specs are these folders that are named after the Stars.

A

It's great to know, I mean I can see it. It has been meticulously uh organized here.

B

It's it's a work in progress, you know in some suspects for years were really the wild west and they were built for the people that were very actively building. We've been more and more trying to up our our level of documentation and kind of make it more inviting uh for people to be involved. So if there are particular pain points that people run into, let us know because we're we don't move fast, but we're trying to make it better over time.

A

My general suggestion here would be if, if in the particular file, if we can have a resection and had that.

B

I've been I've been thinking about that as well.

A

B

Need every every single one of these folders needs to read me I totally agree and I just haven't done it, but if anybody listening wants to make a read me, the first read me for maybe like even the nub just lists kind of the the high level things I will accept that PR I will do a deep review and help you out and get it over the edge.

A

Will share this message out. I am curious about I know. This is not the proposal that we are discussing today.

B

A

Have the meeting planned for this later on, but I found that in this pack 4788? Is it going to be for both clients, like consensus and execution, or is it just execution specific yeah.

B

So that one's um you know often now that we have this kind of merged system, we can have features, eips changes that only affect one side or the other right like 70 45. It only affects the consensus layer, because it's just that application inclusion window, the execution layer knows nothing about applications like it's. It's just totally self-contained in the consensus layer, whereas 4788 is what we call a cross layer. Eip, uh which requires more coordination, requires. More testing is a bit tougher and what that that one does is it's primarily.

B

The heavy part of the load is on the execution layer. They have to kind of add this new pre-compile and expose things and do some State updates, but there is a small change on the execution on the consensus layer and that's to like essentially there's this there's this root, this commitment and it's to make sure you pass it into the execution there. So it's very small you know it's just like give the data to the other side, uh but it does. It is cross layer and does require some testing and specification on on this side.

B

You know, whereas again on the execution there, you can easily have VIPs that don't affect the necessary like if you added a new OP code that did modular arithmetic or something like the consensus layer wouldn't have to know or care about that. But these cross layer, eips they're they're, definitely require more coordination and more agreement and more testing a little bit tougher.

A

I understand we recently have a chat with um with Mikhail and team.

B

A

Six one one zero, so we understood like that kind of proposal are for cross layers, yeah.

B

Yeah anything cross layer is is tougher. It's like like 70 45, that EIP was written uh in the spring at some point and was like very quickly like okay. Let's just do it, whereas if it was cross layer even if it was small and cross layer, it would have been much harder to to kind of get in at that point of the process.

A

Yeah, we totally understand that we want enough time for testing and other things so make sure like, as you mentioned in the beginning, it's no joke changing the running multi-million chain. Yeah, all right, I didn't see any anything mentioned over there. Just for confirmation is there any security concern that client teams, or uh perhaps the validators or users of this implementers of this proposal may be aware of.

B

Yeah I know I mean this is really a other than the fact that if you change things, you have to do lots of testing right, even tiny changes, so that the security concern is making sure it's correct, but it's extremely simple and all of our security analyzes tell us right now: it's strictly an improvement in security. As for people operating validators and operating nodes, it's going to be totally transparent, change, they're not going to really notice anything. It just is to help enable that that confirmation rule. So the big.

B

The big thing is it's a positive change for security and I really hope you know call it by the end of the year that some exchanges and other high value other other applications that kind of expose confirmations to users that they start incorporating this and have a better ux. This I think is really exciting.

A

Right yeah ux is always helpful, like better us is always helpful for novice users like even if big parties are doing that. Yeah.

B

A

Helped with that all right, I think. That concludes all my questions. Related to that. Like uh specification and Technical uh aspect of the proposal now, I want to get into a little bit of a documentation of an EIP, because we have been in discussing the elcl kind of thing like El people are doing, eips and cl people are doing it for the first time, I.

B

A

Know you are a veteran uh author. You have written multiple eips so generally curious did You, observe any significant process change.

B

Yeah yeah I mean so I have written eips in the past, but most of my specification work over the many years has been really contained into that consensus, specs repo, which does not contain a lot of exposition or explanation. It's really. What is the python code that modifies the state transition function? So that's most of what I do right and we've made an effort in this Fork to now that the merges happen to try to unify this process and write eips and better document.

B

All of the changes going into the consensus layer, Tim Baco, really pushed for this people on the consensus side were a bit skeptical, but I think it's going really well, and it's really nice to have a self-contained chunk documented, given a name and being able to be like kind of discussed, debated and tested independently.

B

This is very contrary to like, if you look at Altera, which was the first speaking chain hard Fork, it's like kind of hard to parse, what's going on, it's kind of hard to parse what the different features are, and you really kind of need to be using extra blog posts. Maybe your peep and Eep series to really like understand. What's going on, whereas given the eips and given these a kind of self-contained documents that accompany our spec, we can really.

B

We can just say for it before it goes in 70, 44, 70, 45 and 4788, you know, and they can, they can go look at the names they can look at the abstracts or it can look deeply at the specs. And so that's that's really been a big process change for us so kind of coming to Ben. Sometimes people will still write a consensus, spec update kind of as a draft with no full EIP, just kind of quick, quick and dirty.

B

But once we've really are elevating it into discussion, then we now are going into the eip's repo writing an accompanying document which gives the high level motivation the abstract and and kind of the high level of the really nitty-gritty specification change. But then it links to the consensus effects which then have the like mechanical change. The state transition and I've actually found this really nice uh I was a bit skeptical and I've quite enjoyed it, especially for these cross-layer eips.

B

It makes a ton of sense because, like things are happening in multiple places- and you really just need to like have a single kind of source of Truth in a single place to kind of jump into where they're happening in multiple places, so we're still kind of it's still an experiment. It's still a work in progress, but we're coning in on some standards on, like you know, you have you bullet point.

B

The high level changes in text and you link out to the specific places you know and then on the consensus layer side as I showed. You know we we have a bit of like a format and annotating. You know the different line, changes that are relevant to the different eips, but I think it's going nicely. It's.

A

Quite helpful I was having a chat with Lion tapline 47044 He also mentioned that, though he was not very much convinced that an EIP is needed, but now he can see the value for especially for non-technical people and having an eib.

A

um While it's taken to the same topic, I have a few things to discuss about the EIP documentation. We generally encourage people to have a discussion to link to. You know, share information about the proposal and also invite Community participation. They can let know how comfortable they are or not. I did see the discussion to link for all the claibs, but I did not see anything happening over there is there any other place where people can follow the discussion yeah.

B

As I link in the presentation, there is a also an each research post that initially presented the confirmation rule. So that's kind of a place where discussion could happen. I think really. What happened is this is just extremely simple and was agreed on relatively quickly in the core depth calls, and so just didn't, have much discussion. I guess, one place where discussion does happen is I can share my screen. One more time is when we're doing the kind of mechanical change to the consensus layer. Spec like this is the pr that introduced the change.

B

You know we have this modified line right here like there is. There ends up being some discussion in these. Inevitably because people will review these PRS, so you know photos jumped in and just made a small typo change. You know, Terence is making a note about how we've done things in the past. You know just nothing crazy, but I would say if there's any conversation, the bulk of it happened in the in this PR, um which is interesting an interesting a note. You know anything that bubbled up from this.

B

That say, somebody brought something about security or this or that it would ultimately get reflected in some of the discussion notes on the EIP. But it is interesting that these PRS aren't kind of like directly LinkedIn thought of in there. Something to think about work in progress like I said right.

A

No I understand totally like that was something that people used to do uh back in 2015 to 2017 era, but we generally recommend people to have any kind of discussion in fem the reason being one piece once the pr is closed once the EIP is merged. As a draft, you will come up with Nubia to have the status chain and in.

B

That case people.

A

May lose the context, so I think for transparency and giving full uh context of The Proposal like what, when why? How everything it's useful to have some chatter around uh yeah.

B

I wonder I, wonder if, like these, any PRS should be like at least linked to in The Magician's thread or link two on the EIP, because there's also like part of what we're doing in the consensus specs when we're doing reviews like we're literally reviewing code, we're literally reviewing mechanized code and like GitHub, is very good at like kind of having that all linked together.

B

So I, don't imagine we're going to depart from having some of these discussions in the PRS, but having them appropriately linked somewhere might make sense, I'm actually going to drop it in the uh magician thread. Right now,.

A

Yeah that would make sense, in fact, if you add the each research post as well, people will get more context of what is going on in here and every time if any spec change is happening because a new PR someone did something that we can definitely link it back in the fellowship of which is our regular updates. There.

A

B

Well, let me drop it in there cool.

A

All right, I know this is the first time that CL people are doing it so uh yeah.

B

We're figuring out.

A

A little bit yeah, a little bit of nudge, will help all of them, and talking about that um I understand that this proposal, as you mentioned, maybe a part of pre-release pack right but uh I, see the proposal is still in the draft status. So earlier we did not have the review started so from draft. It was supposed to go to the last call, and in that case it makes sense if you want to keep it in draft.

A

But now there is a review status, which is generally helpful because you know Erp editors will pay more attention. Even Community will start paying more attention when they find it in review status. It's a small PR just you need to create same change of status from draft to review, but I think that would be the most appropriate.

B

I'm gonna do it right now: I'm uh I've written me many aips, but I'm, sometimes sometimes a noob to the process, still so yeah very useful I when you said it was drafted being in the call. I was like, oh that that sounds wrong.

A

Upgrade your best one and when it then we move it to the last call status.

B

It's true it's done or well, there's a there's, a pull request.

A

Awesome, thank you so much and a last question on this one, like the governance and the process. Improvement. If you have noticed any anything that you've seen, is not relevant with respect to present El NCL client uh having the same kind of documentation. What we call is like unified documentation process. If there is anything that we should get rid of, please feel free to share and we'll try to have that proposed in the next eipip meeting and try to work over there.

B

That sounds good yeah I we've we're getting used to it. It's not so bad.

A

I think your nudge for change of process works. A lot I remember seeing an issue created by you about the pr number and I'm very happy to share that now we are almost in a position where we are going to go by this sequential numbering. In the last meeting we discussed about how to do that. So we came across situation and perhaps a solution for this is like EAP numbering will be done and managed by a Google sheet, which is.

B

A

In person managed by the editors, so we will not be randomly allocating PR numbers, but the sequential numbers.

B

So many so many ways to numbers and I I know I realized after I posted that that this was already a hot conversation for editors for a long time, so I don't mean to take all the uh the credit. I know that lots of people have been thinking about this for a while.

A

Right, sometimes, process are delayed and if we get, you know a little bit of support or push from a community that goes faster right.

B

A

Yeah, thank you all right. um I know we are almost close to the Nara Mark. Do you have any message for the validators community.

B

Not a big one, I mean thank you. The Deacon chain runs exceptionally well better than we ever expected it. So we used to think before it launched. You know maybe like 80 would be like the average on lightedness, uh but it's like 99, so 99.5 or 99.9, so um y'all are killer. It's great um and keep an eye on test sets. The NAB testnets Dan test nuts are coming up so test your startups and get ready for the hard work.

A

Very well said so this is going to be the fourth upgrade right: I'll, tear Bellatrix and uh whatever scene.

B

Amazing capella yeah yeah.

A

B

Actually is subtly really really useful to help me? Remember them.

A

You're right, yeah alphabetic order is help helping there. Otherwise, for the El level, we have to go back and check on.

B

Everything like when, when was Devcon, where was Devcon.

A

B

Before that, yeah.

A

Right very well: Jenny Ryan. We thank you for joining us on keep an Eep and talking about upcoming changes with respect to eib 1745 from a strong and proof sketch to a full-fledged weekend chain. We contain our day consensus layer has evolved significantly and we look forward to seeing the proposal on the test net and finally, on the main net with tenkon.

A

On this note, thank you to all our YouTube viewers for watching and podcast subscriber for listening to this special episode on lanco. Do you have any question on this or any other topic? Let us know at epctheters, Discord check out the description for more information and we'll be back with another interesting talk until next time keep watching keep sharing and keep loving, ethereum capitalists. Thank you. Everyone.