Ethereum Cat Herders Beacon chain proposals, 31 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP #34: Altair - Accounting reform with Alex Stokes

Description

Topics covered
-----------------------
1:23 - About Alex Stokes
2:42 - Outline of presentation
3:40 - Altair
5:17 - Eth2
6:15 - Altair - Flagship features
7:22 - How is it different from Ethereum 1.0?
9:24 - Accounting reforms
10:25 - How does incentivization on the Beacon chain work?
12:02 - Mechanics of PoS consensus
12:30 - Consensus
16:31 - What is attestation? What does it mean for a block to be justified?
22:53 - Time on the Beacon chain
24:24 - Duties on the Beacon chain
26:27 - Rewards on the Beacon chain
27:45 - LMD Ghost
28:56 - How is incentivization changing in Altair?
29:40 - What is the main problem that Eth2 is trying to address that Eth1 experiences?
35:43 - Accounting reforms - overview
35:48 - When are rewards accounted for?
37:34 - How are rewards accounted for - so far, Altair and beyond
38:10 - Reasons for optimization - base reward
44:36 - Base reward going to remain the same or will it change?
49:05 - Would there be an increase in APY with Altair?
52:45 - Accounting reform (tier structure) as explained in HF-1
56:05 - Can you talk a little bit about the process flow to propose a feature in the Consensus layer?
48:00 - Fun fact of Eth2 chain

Resources
---------------
Altair: Accounting reform - https://docs.google.com/presentation/d/1zX-Al6iUE_tFomsoJdEpieJT8l6iAjhjPNKd7YpKjZI/edit?usp=sharing

The Limits to Blockchain Scalability - https://vitalik.ca/general/2021/05/23/scaling.html

HF1 Proposal - https://notes.ethereum.org/@vbuterin/HF1_proposal

Core Developer Apprenticeship Program
https://blog.ethereum.org/2021/05/13/core-dev-apprenticeship/

GitHub
https://github.com/ethereum/annotated-spec
https://github.com/ethereum/eth2.0-specs

Consensus Layer Proposals playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxoEw29YmqJtNoFaENUUAREn

Follow at Twitter
-----------------------------------------------
Alex Stokes @ralexstokes | Ben Edgington @benjaminion_xyz | Alita Moore @AlitaMoore85 | William Schwab @William94029369 | Pooja Ranjan @poojaranjan19

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

Follow PEEPanEIP earlier episodes at https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F

Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.gg/tzYmDmF
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/

A

Welcome to the altair special episode on keep and eat a series dedicated to discuss improvement proposals considered for the ethereum network upgrade. My name is pooja ranjan and I'm your host for today's episode on accounting reform with altair networking altair is the first upgrade of the consensus layer chain, alternatively known as e2 chain that is expected on the main net in july, 2021 beacon chain went live in december 2020 with the introducing staking on ethereum network, with close to 150, 000, validators and five active clients.

A

Understanding of any change to the present reward structure or addition of new feature is important to the community to provide an overview of this upgrade and proposed features. We are joined by alex stokes from ethereum foundation and, of course, our own ethereum cat herders. We have special guest ben welcome to the show alex.

A

May we have a quick introduction of you a little bit about how you got engaged with ethereum community and the speaking chain.

B

Sure, yeah, uh hey everyone, so yeah, I'm alex stokes, I'm a researcher at the ethereum foundation uh today I'll be talking about accounting reform in altair, and we will definitely dive into that as we go um to get started, though, let's see um I mean I've been following the ethereum community for many years now and uh in particular, pretty deeply engaged with youth too. For you know the last couple years, I'm very very excited by you know, what's possible, as I think we all are, with uh sort of this vision of a scalable ethereum.

B

So part of that is a series of upgrades that we'll get into to you know, make the network either more secure or more scalable in various forms so that we can have more transactions. um You know ultimately and yeah I mean the first of those is I'll tear.

B

So unless there's anything else, I could go ahead and get started with some slides. I have here.

A

Thank you for introduction, so without further ado, let's peep in.

B

Great okay, so accounting reform. um If there's questions with anyone on the call just you're welcome to ask as we go otherwise, uh we could take some and do like a q a at the end, uh but either ways uh we'll start just with the outline which is you know what is altir, uh you know, why do we even care about it? What are the flagship features that are going into this network upgrade in particular, so there's a couple of them at these collection features, and one of them is accounting reforms.

B

So that's what I'm going to dive in today and hopefully give you a sense for how incentivization works on the beacon chain. uh You know who like what are the validators doing? Why are we rewarding them or you know possibly penalizing them for different behaviors? They take on the network and uh with this feature in particular in altair, it's a change to how we handle the incentivization. So.

C

B

We'll look at kind of concretely what's changing what came before like? How are we upgrading the beacon chain itself uh and hopefully you'll understand why it's better um yeah and then we'll just conclude with a little summary, so yeah first altair, you've probably heard about it. It is a network upgrade that we have planned for the beacon chain, uh so the beacon chain, uh as puja said, launched in december 2020, part of this umbrella of things called eth2. That you've probably heard a lot about in particular.

B

The beacon chain is a first step, moving the ethereum network at large from a proof of work, driven consensus to a proof of stake, driven consensus, and you know that can quickly get very technical very quickly.

B

The point being, is it just a change in the way that the blockchain kind of operates um that we hope is ultimately more safe and secure for the ethereum we have today and that's kind of what I mean here when I say in the future, the beacon chain will host this sort of consensus layer for ethereum.

B

You can think of a lot of the application stuff happening today as the execution layer and, again, I'm sure, if you're watching this you've heard of the merge that I capitalized, because it's the emerge, it's quite important but essentially it'll be taking.

B

You know again the ethereum, the economic activity of ethereum today and moving it to this new home, the beacon chain um to again begin this series of upgrades under the ether2 umbrella, then down the line, uh we hope to even scale things further with sharding, which I don't think I'll talk on or I'll talk too much today, but um essentially it's uh yeah, the future's, looking quite bright uh with making ethereum even better than it already is today.

B

Here is a little picture. That is just a you know, super high level cartoon of what this eve2 thing is. So we have the beacon chain I spoke about. You can kind of think of it as this like yeah coordination, layer, sort of this uh blockchain.

B

We use to sort of administrate the other blockchains involved, and in this case they would be shards, um and in this sense, once we have a sort of sharded ethereum, the various shards aren't sort of independent blockchains in their own sense, but they they host data that then scales up the capacity of the system overall.

B

So it only charges shows like shard one or shard 64 here, but there are actually there would be 64 shards, um and the idea is that you basically have all this data capacity that then you could use to power things like roll-ups uh and various other layer, two scale light solutions you might have heard of so you could imagine now we have this like new proof-of-stake home.

B

That then, is scaled by all this data capacity for these different layer, twos and you could quickly get to you- know a much more scalable ethereum than the one we have today. So um altair, then, is the first network upgrade. We have planned for the beacon chain which right now is happening independently of ethereum main net um or at least sort of these, the execution chain that you've probably interacted with and uh there's again sort of three high-level features of ulterior.

B

There's the sync committees we're adding, and so these are basically a new role for validators to perform and what they do is basically sign off on the chain so far, and by doing that, you can then provide proofs to like clients that this is in fact the correct header chain and then from there like client can only verify these proofs. They don't need the full box, they don't need the full state and you get light clients.

B

And again we don't have time to go into the details on this call today, but basically uh there's a lot of like very neat things involved in the design that make them super lightweight. uh You can even do things like have bridges between the beacon chain, and you know some other blockchain ecosystem, different chains, uh all sorts of fun things you can do.

D

Do you mind actually, if we go back and um how is this different from like the ethereum one that we use right now, primarily.

B

Right so, okay, um you could almost ignore this. There's ethereum one and it's a blockchain and you could almost think about it happening separately to anything you see on the slide here which is what's happening today.

B

So then, what we're going to do with this merge that you've probably heard about is say: okay, we're going to take the sort of execution or like the application layer activity and we're going to basically staple that onto these beacon chain blocks these the red blocks here um and then, on top of that, this, the uh this thing gets into the starting design, but you can basically use all the shard chains here as like extra data capacity which, like maybe one day, turns into like you know, sort of rich stateful execution shards.

B

What it can immediately do is turn into uh data for roll-ups. So then you could imagine, rather than having like one blockchain's worth of capacity like we have today for rollups, you now have 64 more times capacity. um Does that make sense? It's like kind of, perhaps hard without me being able to like draw some things, and I can't quite do that right here. Sure.

D

B

Let's see okay, so we have these flagship features for altair and uh right. So I'm going to be talking about the accounting reforms today and the other big thing with like yl tier, is it actually sort of gives us a practice run as like network operators for the beacon chain uh to do a network upgrade right, um they're, inherently risky. So if we have one of our belt, that's like a lot better than not having one under our belt, and there will be. You know an incredibly important one with the merge that happens.

B

You know in the next several months, so uh yeah there's reasons to do all tier uh as soon as we can and uh yeah we're, also going to get some like very nice upgrades to the beacon chain, um including these accounting reforms that I'll go into now.

B

Okay, so uh just to get this out of the way like to keep this, you know uh in your mind as we go like at a high level, uh we are changing how validators are rewarded on the beacon chain and and from phase zero, which is the current you can think of it as the name of the current fork. uh It's named phase zero for, like kind of historical reasons there were slash, are different phases, uh but we're kind of deprecating that terminology and view of just looking at these things.

B

Those different features to the whole thing so either way phase zero moving into altir. We change uh when these rewards are applied and also how they're kind of calculated and derived so uh first I'll start by just like talking about like what the rewards of penalties even are and then we'll look at the when and the. How and the back cap of this talk so yeah. First, we'll start with how does the civilization work in the first place?

B

um And the point being is: okay, we have the beacon chain. uh This is possibly part of the confusion today. Is that, like the beacon chain, doesn't do much at least as a user of ethereum? I, like kind of don't really need to care, uh because all the beacon chain is doing today is coming to consensus on itself and that's fine that was actually by design, because uh you know we kind of want to design this thing in parallel.

B

If there is something that happens to the beacon chain, if there is an attack, if there's a bug, if there's some disruption, that can happen and we can figure out how to fix it. um As you know, developers of ethereum on the side without affecting the current, you know, economic activity that I don't know what is it four or five submits like some hundreds of billions of dollars? That would be very disruptive if we were to you know, endanger in some way so, basically uh focusing in on the beacon chain. We want to drive consensus.

B

The short answer is we're going to hire validators to do this right very much like how on people work on ethereum. Today we uh hire miners to mine the chain right. They they do this task for us and in reward you know, they're, given the block subsidy access to transaction fees.

B

They're, given you know these incentives to to to mind to do this task so similarly on the beacon chain, there's various duties that we'll see in a minute and uh ultimately we should tune these duties such that they facilitate things like consensus of the beacon chain, or you know, consensus for light clients stuff like this um right, so we'll take a little aside into some of the mechanics of the proof of state consensus because uh we'll use you know, you'll see the things we kind of reward and what to reward later on and again, there's kind of two mechanisms here: there's the casper ffg mechanism and there's the lmp ghost mechanism.

B

So I believe uh well here, just to kind of do this. I have this little cartoon to like show what's happening. uh Perhaps we'll we'll come back to this, because I skipped the slide. So what did I say here right? Okay, so the main thing to realize here is that the casper ffg and this omb ghost process the ways in which we have consensus on the beacon chain, they're, driven primarily by this concept of an attestation.

B

uh A meta station is really a validator in the system right, so if you become a validator on the beacon chain, what you then have to do is every so often you need to say: okay, I think the chain looks like this and you're gonna assign that so that you know, other validators can be certain that you, in fact you know, did actually attest to this and then that's broadcast on the network, and then every validator gets the messages every other validator, and that's how you end up.

B

uh You know deriving the canonical chain um right, so we need condenses on these attestations, so we put them in a blockchain, and so we need block proposals for that. I'm kind of building up these different duties that we might want on the beacon chain and then we'll see that we need to reward them if we make them happen or not, uh and that's what we're building up to so right and yeah. We're gonna reward those behaviors.

B

Now this is what I wanted to kind of show. uh So basically there's, I guess. The first thing to note is that there are two time scales here. So the first time scale is on the order of epochs, which are uh a chunk of slots and I'll define in a second a little bit better. What that means. But basically the way to think about it is on the beacon chain.

B

There's a unit of time called a slot and every slot uh is expected generally to have a block, um and then what happens is after say, 32 slots.

B

You know some number of them that we define in the protocol so with, and that you know on mainnet happens to be 32., so with 32 slots, that's called an epoch and then the reason epochs are important is because every epoch we want to do some processing that doesn't really make sense to do every slot, just in terms of like the overhead of nodes actually doing this processing, uh and so we kind of batch it, and then that also then gives us these two different time scales to run these different parts.

C

Of their consensus in one sentence.

D

Like what is done at the different levels of abstraction of like the different levels of the number of like blocks right, so you have the one block, but you do work in 32 right.

D

So what is like the different task?.

B

Right so you're still so a validator is a testing every slot, but then what you're doing is every epoch you're? Looking at what happened in the previous, you know the previous 32 slots, let's say and then you're gonna calculate all these attestations and then from there figure out. Okay uh was there enough to justify and then, if there's a justification, did that change finality so uh yeah just to round out the thought here these um and you can't see that I'm pointing but but maybe can you see the mouse yeah? I.

C

B

A second okay, okay, so these um these, like taller lines here, are meant to denote epoch boundaries, whereas these short little dashed lines here are these individual slots, and this is maybe a little misleading. But basically, uh when I draw this like big block here, you should think of that, as just like a summary of all the blocks in an epoch and the reason.

B

Why is because for ffg we actually only look every 32 blocks and say: okay, um you know kind of what's happened here, and so that's where you get this like coarser, grained, behavior, looking epoch for epoch, whereas for any given epoch you can actually resolve into you know this lower level, more fine, grained structure and it's the slots. Each slots have blocks, or maybe they don't. um This is what I tried to do here. There's I guess in black. We have this canonical chain, the head of the chain.

B

Is this like golden block up here uh and then we have. You know, for example, so, like this epoch was justified, but then basically it looks like it was an orphan for whatever reason right so validators decided to go down this part of the chain, then within the segment of the chain. Here you see, there's still orphan blocks, uh for whatever reason right, validators did not choose to build on top and.

D

I just wanted to um so first off what is an attestation and then also uh what does it mean for a block to be justified.

B

Right, okay, so an attestation is this uh message that a validator will produce um the way to think about it. Is that once an epoch, a validator has to make an attestation, and that is a signed message that says what their state of the chain is. So it's like literally I'm a validator, I'm running a beacon node. I have my local view, the network when it's my turn to test which is what's in epoch. I build a little message and I say: okay, uh this is the head of the chain.

B

This was the last justified epoch. This is what I think the next justified epoch should be, um and then some other metadata just to help with the counting does that make sense for what an attestation is yeah.

D

That makes sense: um okay,.

B

Adjusting and then yes so justification, so this gets into casper ffg, but essentially it's how we make sure the chain is secure. It's how we produce finality.

B

The way to think about it is that if two-thirds of validators across the entire set have attested to the same block being justified, uh then it becomes justified if that makes sense. So basically you have this like threshold of security, which is two-thirds and once enough of the validators have attested to the same thing by two-thirds, then uh it's justified and the reason that's important is because if you justify a block that has been justified, then the sort of grandparent block is finalized.

D

B

Dense yeah um and so yeah, I'm sorry, I don't. I didn't have like a good good graphics for this. But basically justification is important, because if you have, if you keep justifying things, then that means that you're finalizing things and finality is important, because it is actually this like very strong property of consensus, which is that if you finalize a block in the chain, you cannot finalize the conflicting block without demonstrating without proof that you can slash. You know some huge amount of validators say one-third up to two-thirds right.

B

So um that's actually, where we get the security of proof-of-stake is because uh you know, let's see, I used to have numbers on this, but basically yeah. It's like hundreds of millions of dollars, if not more right uh to basically that you have to be able to burn of ether before you can like actually slash uh or before you can actually finalize a conflicting chain, because that's slashable that makes sense.

D

uh Sort of I think it it definitely is, is dense. I think that that's kind of unavoidable, um so maybe we should move on. But okay, I think one thing that here that is still confusing me is like so you have. So if I were to summarize like what a what justified means, it basically just means like we're going to use this block now, right, like this block, is valid and then so what like? What first off? Is that correct?

D

If you say it's justified, is it valid.

B

A valid right so yeah, so one way to think about it is that you could so there's like all the blocks on the network that I see some subset of those are valid. Some some subset of those, then other validators have justified uh via our collective action on signing off on them.

D

So it's like, we want to use this in in our chain.

B

Right yeah, I just we think this is the next justified block in the chain, and uh by doing so, by committing to this we're actually putting our our stake. Then, when it's proof of stake right, it means we've put down this deposit as a bond and.

C

When we sign that, when.

B

We sign these messages. What we're saying is, if you can also show to the chain right, if you can, if you can demonstrate proof uh sort of cryptographically that I've said something conflicting on the network, then you can actually slash my fund, and so that's where.

D

B

D

So then you lose your stake.

B

D

um And then so.

B

This is the this is like the strongest incentive to not do bad things.

D

um So in here it's basically like there was one that was justified, but does this mean that, like it got the two-thirds of people saying that it's correct.

B

Or right, so, if we're talking about this like this, the quote orphan block, uh basically some number- we actually don't really know uh not not a majority right. So not now this two-thirds threshold uh attested to this, but then for some reason, validators ended up going with the block and epoch sort of e minus one.

B

So yeah again, maybe that was like too much detail for this crew cartoon. But I was just trying to show that, like you, can uh it's sort of this like more dynamic property than just like uh you know, um just going block by block.

D

I'm I'm just trying to kind of um piecemeal a little bit, so I hope you um so thank you for your patience with that. um But just like kind of like just one last thing, which is is so in other words here right where you have like the the e negative two grayed out, like the the validators that said justified that lost their stake.

B

uh No, so right so maybe uh justification is a bit strong here. So maybe, uh let's see, I suppose. What makes more sense here is that uh some number of validators have tested to this block. I think it's more what I want to say, um and you know it's not it's not clear what the number is. It wasn't that many and so like the way to think about this is like maybe at epoch, minus three like e minus three uh everything was okay and then an epoch e minus two.

B

There was some like you know: someone cut uh underwater, cable and like suddenly, there was a huge network partition, and so you know maybe like an eighth of the validators, saw this block and they started to attest to it because that's what they saw and they're just doing, you know what they expected to, but the everyone else couldn't see the block for some reason until it was like too late.

D

Thank you very much. I think you can move on now.

B

B

Okay, the point I was just trying to make is that there's time on the beacon chain, um time is divided into slots. And again we just you know, pick a number. uh This number is 12 seconds on mainnet and you know it basically comes down to how much processing do we expect to know to do in a slot and that kind of sets a cadence for like the rest of the protocol um there's. So the protocol is divided into slots and then yeah some number of slots form an epoch.

B

So this is like just uh again just revisiting this idea that you know we have maybe buck e here epoch e minus one. It keeps going within each epoch, there's slots right, so you have the first second third slots in epoch label, 0, 1, 2, going up to 31 and again just a schematic for this and just to make this concrete.

B

uh This is from mainnet just like an hour or so ago, right we're in slot 1.26 million. uh You know epoch almost 40 000., so you know the beacon chain. Genesis was december 2020 and then basically every 12 seconds we go the next slot. There should be a block in that slot and generally, there is on main net um and yeah every 32 slots bigger than next epoch, so there's a sense of time and the time keeps going.

B

The reason this is important is because the duties we're about to get to are, you know the way we think about them is what can you do in a given slot or a given epoch.

B

Okay and yeah just to round this thought out a bit more uh there's duties, we've mentioned so like at the stations are producing the block right, which then would contain attestations and like some other operations, but basically uh you would expect one block per slot and blocks have attestations, among other things, like I said, and then those attestations then are testing two particular slots and it's determined by randomness in the in the beacon chain itself as to which validators should attest to which slot each epoch that shuffled each epoch and that helps with security and avoiding like censorship and also like different inclusion things.

B

That could happen um and again I have this this cartoon here, which is saying: okay, there's a slot s, plus one plus two plus three plus four plus five, uh for example, in slot plus four, there was no block um just again that validator might have been offline or they had a problem. You know a bug with their software locally and they couldn't make a block on time.

B

um Then you see these arrows that I drew are kind of supposed to refer to. You know active stations in each block that refer to previous slots, um so yeah. Just to give an example like with the block at s plus 5, oh wait. I have the pointer, so you know here, then we have this arrow right. So there's an attestation in this block that uh is was made by a validator that was assigned to a test to this slot, and then it was included on chain in the slot.

B

So there's duties we can do again. uh I don't want to like throw too much. You know at everyone at once, but the point being that there's duties that you do on chain and then you have rewards that happen. uh You know these rewards or penalties are given in proportion to your performance and again the takeaway here is just that. There are things that you're expecting to do as a validator on chain on certain times, and uh you know we we hope to drive consensus uh by rewarding people for doing what we want.

B

um Okay, which is what I said here, basically yeah, it's given all these things happening on the network. We bundle them. You know certain.

C

Validators bundle them.

B

Into blocks other validators make the messages that go into the box and those boxes shipped out to everyone. So then you can say: okay, based on the blocks, I see I can figure out. Okay, this validator, uh you know tested in these epochs. uh You know very timely and like a good manner, and so because of that I can say okay, they should be having this much ether like this vegeta taken away. um Moreover, then, because of the aggregate behavior everyone I can say, oh like the chain was finalized or the chain was not finalized,.

B

And uh concretely, these are the things we want to think about rewarding. uh So there's like some some properties of the various behaviors. So we have a testing and proposing at the high level uh right of testing proposing.

B

So when we attest, uh if there's a correct, ffg source, a correct ffg target, or if the attestation has the correct head of the chain, then we want to give validators incentives. We want to give them rewards for doing this correctly and again. It might take us a little too far afield to like get into concretely what source and target are. uh But I guess I can give uh yeah just briefly like uh if this.

B

If this arrow is a justification, then the source you know would be where it's pointing to and the target is where it started and the idea is you want enough validators to do this, such that you then build up to this. You know sort of safety threshold of the stake.

B

um Right and then also you get the correct of the chain, so there's a part actually.

C

B

Talk about here, which was lmd ghost and then basically what I think about it is that you have associations coming in every slot and you actually can use the weight of those attestations to influence the fork choice on like a very local level, and uh you know I could have drawn weights on these different blocks that you might see. um But again, that's perhaps different different uh talk.

B

So we want to reward those things uh when we propose, we want to reward proposers themselves for including attestation, so you can imagine validators proposing blocks but there's empty blocks or something like that's not helpful, because you need the attestations on chain to know. You know.

B

What's what's canonical and what's not uh so we want to incentivize that and then also in altair there's a new type of duty we can perform, which is the sync committees, um and these are the ones I mentioned, that are signing off on each block and then basically providing these as like proofs for light clients, so that they can only efficiently follow the header chain so to speak of the beacon chain and then also of course, we want proposers to get some incentive for including those. So that's new in altair.

B

uh I believe, there's gonna, be other uh sort of episodes in this series talking about the other features of all tier, so I'm not going to get into them too deeply, but they exist.

B

Okay, uh I guess I'll just briefly ask if there are questions so far and if not that's okay,.

D

um I guess I'll I'll ask one question. um I guess what is the main problem that you're trying to address that you think e2 is trying to address that each one experiences.

B

Right so there's a couple things um I suppose like two of the most important ones or the first one is. We want to move from a proof of work, to a consensus, to stick driven consensus and there's a number of reasons that we want to do this one of them. uh I mean honestly, the end of the day. I'll claim that proof of stick is more secure, um mainly like the intuition.

B

There is that you have representations of consensus actors in the state of the protocol itself, and so you can do more fine-grained things around incentivizing them and also penalizing them, and actually you know we'll continue on and you'll see kind of concretely what that looks like, but basically you have more tools at sort of the protocol level to like deal with bad behavior. So you can imagine, then that, like proof of state could actually be more secure than like a proof.

B

Work setting um also another one people really talk about is like the energy consumption, uh so with proof of stake, you're really just running some computer software, there's no sort of race to the bottom to like dump as much hash power as possible to quote mine the chain.

B

That's one thing: another big thing is again this this starting idea where we now, basically, rather than having like one block so like one way to think about it, is rather than having one block we're not like one sort of regular sized block.

B

We're not gonna have one like massive block, like maybe one 64 x block, um and then what we need to do is sharding is do this in a way that we can still make these huge blocks, but they are processed in a way that uh you know keeps it uh keeps the system able to be verified or validated by. You know regular sized uh nodes in the network and that's again to maintain the decentralization and.

D

B

D

And so with the idea with that essentially be like um 64 times as many transactions per block roughly.

B

Yeah roughly- and you know so all these like dashed arrows here- are like references between the beacon chain and the different shard blocks, and um basically, what you can do is say. Okay, if I have uh you know some, a roll-up block that happened and shard one. This block b2, that's labeled. uh Basically, then I could like even make proofs about that role: sort of the transactions in that role, block that giving proofs about and some later shard block on, charge, 64 and do something there and you kind of coordinate that through the beacon chain.

D

Okay, thank you. I think that's.

B

Okay, is 64 shards a hard limit, or could it go beyond that? Theoretically, okay, so it could go beyond that and actually vitalik just wrote a very good article about some of the rationale and like how we get to 64. and it turns out that maybe you can go a bit beyond 64, but uh 624 is actually a pretty good number, given all the other parameters in the system. I can send you a link to that after, uh but yeah it's going to take us too far afield to yeah.

C

B

Now, yeah great um so yeah, so 64 is good.

B

uh It could go more and like again, the high level intuition is that, like, if computer hardware gets better, then we can have more shards so like, for example, if um you know, if we suddenly have fiber optics everywhere then, like maybe everyone has like much higher sort of average bandwidth and then maybe you could imagine having these shard blocks get bigger, or maybe everyone suddenly has like much faster computers somehow and then so you could imagine, uh you can do more computation at the slayer one versus layer two or something like this. So.

D

This was just kind of a random kind of insight that I've seen kind of off topic so feel free to stop me. But one major concern that that I have with like as far as ethereum is the archive node and the size of the archive node and like just kind of the size of the history of the state um and like so.

D

If we're doing you know 64 times as many transactions and wouldn't that expand the size of the archive node or basically expand the necessary storage to like as a baseline for like as like validators. I think right, like.

B

Yeah and even just regular users right. So, if I have like you know, if I send you some die in a roll up uh on like in block b4 like I might sometime later need to know that that happened, and so, if I, as a user, can't go find that block or, like you know, get my data, because I.

C

B

It locally or something right like it's tricky, so so, yes, uh the intuition's correct uh there is like an overhead in this sense, because yeah there's just more data that everyone has to be responsible for. Essentially, um I guess the way that you know it's.

B

It's okay, is that, like disk storage is very cheap, especially sort of cold storage or like long-term storage, so a way to think about it is that there's sort of like um like a locus or like a focus around the current head of the whole network and that's what validators need to be responsible for and like keep track of and that actually kind of puts its own bottleneck on like how many shards there can be in all this um and then yeah there's a separate question of okay.

B

Historically, you know once we once everyone in the world has agreed that, like you know, the state of the beacon chain 10 months ago, is this: uh how do we handle serving that data and yeah? It's, uh I think, there's still some research questions to be addressed. An analogy here is like the internet archive, so the internet archive tries to archive most of the internet and I'm not sure you know how they do it basically uh like at least all the details, but um you know they have a good chunk of it.

B

You can go to like look at various web pages at different points in time and so you'd have a similar. You know thing here. um The article I just referenced that vitalik wrote also touches on some of this as well so worth a read. Oh.

D

I will read it definitely yeah.

B

I mean we can talk about this, but uh we won't get to.

C

The rewards so, let's let's but let's move on that's getting off topic. Okay,.

B

So again, like I mentioned, there's like when and how these rewards are happening um and yeah, maybe this is getting a bit too in the details, but um the way that they happened before altier is you have pineapple stations, um which are these data structures derived from attestations that just record your timeliness uh for each validator's performance and then that then, would go into the rewards uh every epoch? You would use these to figure out.

B

Okay, uh a validator gets this much or they lose that much for either doing or not doing some behavior that we just discussed.

B

Let's see so how's that changing in altair uh instead of having these pinning attestations, we're now going to have participation, flags which are just like it's a very compact bit field, um and then we're also going to in real time rather than what's an epoch, we're going to mark participation for each validator.

B

So I'm going through this really quickly. uh So um yeah, it's participation, flags. uh Again, it's a bit field, there's only three that we need now for the various things we want to. You know incentivize that I mentioned with attestations, there's more bits for future rewards right, so like sharding or different things like this, that we introduced in the future.

B

um The reason we care about this there's basically a smaller footprint on chain uh compared to these pending atta stations, it's more extensible and also doing these that just doing the sort of accounting fractal stations in real time, rather than once an epoch smooths out some of the loads. Rather than doing like a bunch of computation during the epoch once an epoch, uh you can kind of do some of it and pull it and smooth it out across the epoch.

B

Do it per slot, uh then there's like the how and yeah I'll kind of just zoom through this. So this gets out of the question you're asking um we want to reward validators for their job. uh It scales with the amount of validators there are so as there are more validators, you end up with basically giving smaller rewards per validator and that's what what this chart shows so yeah right now. This came from the launch pad just a couple hours ago: there's 4.8 million each staked and yeah.

B

The apr is around seven percent um right, so yeah again I'll just kind of zoom through this. But basically the way to think about this is that when we want to design the protocol, we we have a high level invariant that we want to maintain, which is basically giving out one base reward per epoch and a base reward is kind of this. Just like fundamental unit that we just kind of make up. um You know it basically turns out to some factor.

B

Sorry, one factor of gigaway. um You know again, that's what you see here. Is it's scaled by the amount of stake, so as the stake increases, this overall base reward gets smaller and that's how you end up with the chart like this um right and then essentially what you want is in the long run, you want every validator to be able to earn up to one base reward per epoch.

B

Let's see so yeah there there's changes to when you know these rewards are happening and now there's changes to how, um let's see so, the the base reward um and again, like perhaps it's too level for us to like just step through the code here so yeah. I think we're we're keeping a good pace um in terms of like how rewards were accounted for then uh in phasera before altier.

B

It was more that one based order was given per duty and yeah like. I said this is like kind of ad hoc and it actually led to under-rewarding proposers, uh which may be the question you mentioned. That might be part of it is that uh there actually, I think, will be an increase in rewards for proposing uh which might lead to that increase.

B

So, um let's see instead and out to here uh right, okay, so rather than one basic word per duty, we're now actually giving one base reward for epoch, uh and the cool thing here is that we have the system of weights that I'll show in a second and the cool thing with the weights is that it just makes it easier to kind of get correct.

B

um You have the different task right, so timely source that was the correct ffg source I mentioned earlier. Timely target is the correct ffg target I mentioned earlier, then the timely head right. Is it testing to the correct head of the chain for your attestation?

B

Then you have these other rewards for the sync committees and the proposers right and the idea is that that's all part of one sort of piece of the pie relative to the weight denominator and again it's just the system of how we like account for these things um and it's easy to get correct. Hopefully we'll see that in a second, so here's this pie. I took this from the annotated, spec vitalic certain there's a link at the end of the slides here, but basically um definitely go read the annotated spec.

B

If you want to learn more, uh it's very helpful and like covers a lot of this and yeah, so the idea is that.

B

Rather than kind of for each one of these roles here, giving a base reward, we now say one base order is divided this many ways and it turns out it's just easier to get this correct, it's easier to change the weights if we need to to like change different incentivizations.

B

So one thing you can see is that, for example, timely target is one and a half times timely, head and timely source, and the reason that is is because the target is what kind of drives this ffg process so like the the source kind of has to be correct for the attestation to even be considered, and then once it's considered. uh The target is then very important because it tells you the next justified block in the chain.

B

That's why it's rewarded! You know a bit more than the others is because, uh if you have this, then it kind of ensures that you have justification going.

C

So that you have.

B

Like a healthy process of finality unfolding, so it's very important, so that's why it gets an extra weight uh and it's like really straightforward to do this with this new system of weights that we have, then you see an all tier like I mentioned, there's the sync committees. So then you have another allocation for them and then the proposer uh in the various capacities then has like an eighth of this overall high as well.

B

So this is the other high level. Change is like how we think about this base reward on top of also, when we're accounting for the attestations um and again yeah just to run this out. So with this difference in the base reward. Basically, it's just easier to think about to reason about it's easier to get correct and uh it also yeah it scales better moving forward.

B

So yeah again, uh maybe I rush through some of that. So if there's any questions, we could go back and revisit it. Definitely um just to summarize right, so the alternate fork should happen in july or august. It's looking like uh here's, the annotated spec that I mentioned definitely go check that out. uh You can dive into the e26x themselves all the different. You know these code samples I have here are from the eth2 spec directly right, and so you know that's where we go to.

B

um You know to actually specify what the beacon change should do.

B

And oh, I wanted to give a shout out to the core developer apprenticeship program, so piper mariam's working on this and basically, if anyone's watching this, and they want to get more involved. They think this stuff is super interesting and exciting, which it is by the way, uh definitely check this out. um I believe it's set up sort of like a summer internship uh to onboard more core devs, and you can refer to those blog posts to learn more about that so from here yeah.

B

If you uh have any questions or like want to reach out further, like I'm happy to like you, can just dm me on twitter, for example, on at our alex stokes and yeah, I'm happy to just like point. You either answer questions or point you to like resources uh in order to learn more so right, okay, that was the end for now. If there's any questions for those of us on the call we can like go back to something.

B

If I like went too quickly or if there's more general questions that pooja had we can, we can answer those.

E

So first, actually I just wanted to see ben you know we have the privilege of having uh then you're on the call with us. Is there anything that you wanted to discuss or dive into a bit deeper.

F

I'm here to learn and- and I learn things so thanks alex.

B

Oh yeah, of course, I'm glad you could join.

E

All right so then, uh maybe maybe I'll I'll, take a shot after that. um So, if, depending on on uh how well uh how well, I understood- um I'm not I'm, definitely not nice to poor dev so uh and it sounds like the the event altair in general is around a number of optimizations about, as you put in one of your slides, how we're um how there's how the rewards are distributed and what they're just being distributed for um aside from just the efficiency gains.

E

Are there specific reasons with regards to the merge or sharding, where that it becomes more beneficial to have this structure, or is that really just an efficiency, optimization.

B

Yeah, no certainly, um I would actually say these things that you're picking up are like probably more important, which is the extensibility um so yeah. There are some efficiency gains that we have um things that should again lead to like a smoother operation of the of the beacon node. But again the cool thing about the system of weights. Here is that if there is, you know, okay, so, for example, we all went to incentivize validators to like get shard headers on the beacon chain in a timely fashion.

B

Right because that's how we think come to consensus, jumping all the way back.

B

I should have their way to do this. Sorry, but jumping back here. um You know these these.

B

These dashed lines happen by including headers of those shard blocks on the beacon chain and then we'll want to incentivize that, and so uh you know, it's now actually really straightforward, jumping back to uh exactly yeah, because it's just like okay, now we have another, like maybe one eighth reward, or you know figure something out um and the reason this is an improvement beyond what we had is that the way it worked before is that basically we didn't have this pie and so the rewards kind of stacked in a strange way, and that's actually how we ended up.

B

uh I believe under rewarding proposers is because we basically said a proposer gets one-eighth of the base reward, but it was like per duty because that's the way that it was structured in phase zero, and so now we can say: okay.

B

Well, no, you get one eighth of the base reward and that's again this is a more like, consistent and coherent way to think about it, um and it's ultimately just to say: okay, uh when we have this invariant, we can now like reason about in other places, uh for example, if like proposer rewards, are like radically different than some other reward, then maybe there's some weird incentive, where, like a proposer individually, can do something like since they're other validators on chain right and then there's like weird attack vectors.

B

So the point being it's better for analysis and like just generally reasoning about the spec and yeah there's this like forward extensibility, where now we can change these incidentizations and we can do it kind.

F

B

E

Sorry, looking for mute there um does that mean that, as new rewards are sorry as new uh duties that are rewarded that are incentivized to get passed in for intro, for instance, taking your example verifying the shard headers? Does that mean the base reward is going to remain the same? It's just being divided differently, or is the base reward itself going to change as new layers get added into youth too, and that might be out of the scope of this conversation.

B

Well, it's a good question um yeah you could imagine, but I I think that's part of the benefit of this design is they're they're different levers to move right, so we could say: okay fix the base reward.

B

The base reward, then is divvied up in this way, and we could just say: okay, take another chunk out of here and give it to the shard rewards, um but I mean I think you raised a good point and I haven't thought about this myself, but I think it would make sense to say: okay well, the others are doing more. There is this overhead now for running a shard node on top of all this.

B

So then, maybe the base reward should go up right and that could be something like uh changing the space forward factor um yeah.

E

I was going to say once you have that as a variable itself, that also just becomes something that can be varied depending on the situation in the ecosystem.

B

E

B

You know there's all these knobs um someone has.

E

To figure out what the knob.

B

Should be yeah.

E

All right very nice, I'm gonna pass over to puja.

A

Thank you, william. uh Thank you, alexis for the presentation so far. So if I may come back to that question again, it's like because this is a generic question for people uh in general, so uh this pie chart I'm assuming that this is the way of distribution. May I repeat, the question, uh as is asking would be great to get confirmation of the block rewards first taker, so, uh like this pie chart, I believe, is going to help with that.

B

Right so the pie chart is just how the different uh block rewards would be allocated so like, for example, uh as a validator uh you're going to be a testing once an epoch. You are, I think, just looking at chain data even to date, you're like very likely to get the source correct. So you get the 12th out of 64th reward there. uh Validators can generally get this timely target. So then you get the 24 out of 64..

B

uh In the long run you will eventually propose a block or be on the sync committee so that you get those rewards um and then again you have to get the timely head which- uh and this is really digging into some details, but uh the timely head seems to be the one that is hardest to get and like part of that has to do with like block propagation on the network, which again is like a known issue amongst the developers and something we're looking into, um but yeah I mean ultimately.

B

So I guess maybe if you would repeat the question, uh because I thought it was something more about like you know, percents changing right, I think more about you know like they would want to understand. What's going on with this graph.

A

Right uh so yeah, that is the question like uh it is assumed that it's increases from 3 to 12, but uh if that is directly resulting into 8 or more in increased api in future, or something like that.

B

Right so I haven't done these apr calculations myself um and I'm yeah. I guess I don't have like a nice answer to how they would immediately change an altair.

B

A lot of it will just depend on validator performance, and uh generally we shouldn't be doing anything to disrupt that um there is, I think, uh it's like a ethereum calculator. I can look for it, but basically there is like a rewards calculator that someone maintains.

B

um Then maybe you know because I think it's by consensus or someone in consensus.

F

Yeah colleen myers put something together, but I don't know if it's up to date with altair I it's the overall rewards per uh the overall issuance rate without uh targeted to be the same as currently. Is that your understanding is that a design goal.

B

Yeah, I I don't. uh Let's see.

F

Yeah, I mean we'll, basically, will this graph remain the same before and after, although is is right.

B

Yeah, I don't see a reason it would change like, for example, like again like at the high level. It's like that's more a question of the space forward, factor which I don't believe that's changing. um The different allocations would have some impact, uh but yeah. I don't think there should be any change there.

B

What is more, what is more relevant perhaps for validators, is that there are different features. So let me go back to this other slide here.

B

uh These different flagship features so like, for example, um changing to changing the inactivity penalties, so those actually might have like a much bigger effect on what a validator sees in multi-year compared to this part, in particular, the idea of the reforms was more to maintain behavior, but keep it uh either improve the efficiency like we talked about or again make it easier to reason about either from a spec or an implementation. Standpoint.

A

Got it so I have another question related to uh you know the proposal when it was proposed according to initial proposal, that is the uh hf1. The document when it was floated, uh including all upgrades feature account. Reform is proposed for tier one and tier two. So is this uh proposal document uh still good to be referred to? That's number one and it's so. Could you help us understand in simple terms, the basic difference between accounting reform for tire, one and tier two, maybe uh with respect to connectivity, leak.

B

uh So I can, but I'm not sure what the tiers mean.

F

I think vitalik uh originally proposed two accounting reforms uh and I can't honestly can't remember if we adopted them both or just one of them. It's.

B

F

B

So there's there's a number of things that have been in the pipeline, so there's perhaps almost even three and two of them are here which it's not going to be clear. What I'm really talking about, but basically um so yeah we could say one of them is this change to the participation flags that I kind of glossed over, but basically it's just like how we track performance.

B

Another one, then, is how we handle the weights of the different words for the various tasks. That would be another one. Then there was another one uh that I think we've tabled for now, which is basically um changing. How rewards are counted uh so really, rather than doing it say, rather than hanging out rewards every epoch.

B

You would maybe wait every 64, epochs or something like this, and the reason you would do this is that if there's like an attack chain that basically has many mini skip slots and then a block like somewhere far out, uh that then makes a beacon, node have to go and compute. You know all of those slots up until the new block um and if you could basically defer a lot of the epoch. Processing uh until these like points, it helps with the overhead there.

A

Right, yeah that that was my like uh first question. If we are still following that documents or we have moved.

B

uh Here we go okay! Oh I see okay, okay, uh right pending.

B

uh Right, a lot of uh okay, so yeah, so all of okay. So all this is in here um we are looking at these four choice changes, but they are, uh they can happen kind of separately to the hard fork, so we can kind of ignore those and then yeah, so tier one is what I've been talking about today, um with getting rid of the pending attestations having the bit fields of participation, flags and then like uh also how we sort of compute the rewards and then now tier two. This is the inactivity.

B

Links uh that again is should probably be a separate talk, and this is what I was just talking about with these empty epoch transitions and that's actually been deferred. For now,.

A

Great yeah, that was my initial question, because we we find a lot of documents, it's important to know what is like the latest document that people may refer to. So I mean this is my last question. I know we went a little over a time. This is my last question that is related to the process. Actually, I'm just trying to understand like this altair is a feature-centric upgrade.

A

So, unlike the ethereum execution layer chain um like uh there is specs available for a beacon chain, and I assume that makes it simpler for people to if they're suggesting feature to just create a pull request to the main expect. So I'm curious to understand how this is identified in the first place like was that the part of the plan before the launch- and we are just implementing it- was it decided in the phase wise? uh Just if you could talk a little bit about the process flow?

A

How how any feature is proposed to be um included in upgrade.

B

Sure yeah, um so I mean and like concretely there, you know it's an open source project. uh You know again, I put the link here on github, ethereum eth2o.specs.

B

uh You know, and you know we can and do have people either on the research side or on the implementation side right that are like actively working on this stuff. There's a ton of activity, so many issues, so many pull requests uh basically trying to figure out yeah. How do we make you know? A nice beacon chain um definitely encourage contributions by anyone, who's watching or listening. um You know to get involved if they're, if they want to, um then maybe on like the medium term. It's like how.

B

How did these you know where the features come from? How do we decide on them um for altair in particular, like a lot of these were things I think that we're already in the pipeline, in terms like, for example, with light clients right like it's, been a design goal since, like you know, for years now, to have efficient light clients uh for the beacon chain, um and that's so that we can do things like have efficient bridges uh also have efficient light clients.

B

You could imagine replacing metamask that everyone uses with a light client in the browser right and that would actually contribute to decentralization of the network at large, because you're, not relying on, say, inferior as this like centralized provider, efficiently, clients, let you do that um and then some of these other things in terms of again, like the rewards accounting that we've looked at today uh and what else are the inactivity, penalties that we have uh I'm trying to get back to the these features right, so then activity penalties.

B

Some of these are things where yeah it was planned to make certain constants like less punitive, so that it's uh are actually more punitive, so that it's um you know easier at the beginning for the genesis, validators to kind of do things and work through bugs and their setups, and also the software and uh yeah. So I guess a lot of these things were kind of already planned or, like you know, there's ideas around how to improve things that have been floating around for some time um yeah.

B

I guess that was a bit rambly, but does that help.

A

Yeah, it does, I mean, like we are also part of process improvement group and we understand how ethereum 1.4 chain works. This is something different like something new, but we find it like it's getting effective, just creating full requests and doing this. So I was just curious to understand how this process works. So yeah.

B

Right, yeah, okay, sure and yeah. So then maybe I kind of broke it into like smaller short and then, like medium term things and like larger term things and like larger term yeah, it does, I would say, pull into the process.

B

You know kind of how we have all core devs today, uh there's like a eth2 call where you know everyone involves, can kind of talk about these changes and discuss them. I imagine over time like, for example, in light of the merge right like you'll, see a lot more overlap between different.

B

You know, parties that might be a bit separate today, uh just because you know we will all be working on the one thing we call ethereum.

A

Sure definitely awesome. Thank you so much alex for joining. uh It was a great overview of the upgrade. um I remember uh this discussion started late uh in december and, like early january, uh the client team started working on it and uh and coming up with this upgrade. I think this is incredible yeah, so for all our audiences, I would like to throw a fun fact of the e2 network that is also consensus layer chain over four percent of total each state, and uh we have over 147 000 validators on the network.

A

As of now, that's a lot of money, a lot of interest and a lot of uh developers working on it together, alex is um a researcher at ethereum and a contributor to the beacon chain. Research development work follow him at twitter for his live, tweet of consensus, layer, implementer's meeting and other useful resources his twitter handle is provided in the description box. Below on this note, uh thank you for watching I.

A

I hope this episode on accounting reform may have answered some of your questions, but it seems like there are many more questions that people would like to understand. So uh do share all these questions with us. uh David and cat heard us you can reach us on the ethereum cathode as discord and we'll be happy to arrange another session and direct questions to the um researchers and developers of consistent stair chain.

A

Thank you so much alex. Thank you. So much ben for joining today. Great.

B

Yeah thanks for having me uh thanks, everyone who joined.

A

So next week we will be joined by vitalik, viterin and danny lang to talk more on this upgrade stay tuned. Do let us know which proposal or feature would you like to see in the upcoming episode, as always, we'd love to hear feedback and improvement suggestions, don't forget to hit like and share keep watching, keep sharing your love with ethereum cathartis. This is all of us signing.

A