Ethereum Cat Herders PEEPanEIP, 5 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP #30: EIP-2124: Fork identifier for chain compatibility checks with Felix

Description

Topics covered:
1:23 - Fork identifier
2:21 - EIP-2364 is using the fork identifier
2:42 - Why need a fork identifier?
3:20 - EIP-2124 Overview
4:10 - Common network id
5:20 - Why need a chain id?
7:25 - What is a fork identifier?
7:50 - Fork hash
09:08 - What does block number refer to?
13:00 - What is Fork next?
14:14 - Purpose of fork identifier.
16:16 - Impact of two incompatible nodes connecting
19:45 - How POW nodes decide on which chain to sync with?
22:11 - How does fork hash address concerns?
25:12 - Three-way forks
30:25 - ENR
31:30 - What if testnet and mainnet have the same block number?
35:35 - About EIP-2364
38:11 - Why did Geth choose the EIP standardization process for 2364 instead of just updating the repo like Eth63?
41:25 - Status of implementation in other clients
45:45 - What could be the possible reason for the delay in standardization of this proposal, any blockers?
54:50 - Fun fact about EIPs

Resources:
EIP-2124: https://eips.ethereum.org/EIPS/eip-2124
Discussion: https://github.com/ethereum/EIPs/issues/2125
EIP-2364: https://eips.ethereum.org/EIPS/eip-2364

Follow at GitHub or Twitter:
Felix Lange @fjl (GitHub) | Alita Moore @AlitaMoore85 | Brent Allsop @Brent_Allsop | Pooja Ranjan @poojaranjan19

EIP-778 with Felix Lange - https://youtu.be/TVG4Xb-YDiY

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 30th episode of peep, any an eip dedicated series where we discuss an ethereum improvement proposal and understand how it is going to make ethereum even better. I am your host pooja randy and today we are going to talk about eip2124. That is fork identifier for chain compatibility checks. Yeah eip2124 is a standard track.

A

Networking proposal created in may 2019 and currently is in the last call it's related to discovering nodes currently nodes in ethereum network, try to find each other by establishing random connection to remote machines that look like ethereum node in the hope that they found a useful peer. A lot of time and resources are wasted, especially for smaller networks, so this eip proposes a new identity scheme to precisely summarize, the chain's current status with genesis and all applied forks by providing a generally useful fork identifier to understand what is the focus identifier and this proposal?

A

Let's welcome our guest felix wrong. Thank you for joining us felix without further ado. The floor is all yours.

B

Okay uh um yeah so um regarding the fork identifier um yeah, so this uh has been around for a long time. uh uh Specifically it's been around for about two years. It was implemented while the ip was written, so it is already implemented for a long time, also in most clients anyway.

B

So at this point it can be considered just part of the standard and in fact it is part of the standard network protocol, since the eth protocol version 64.. So.

B

um Basically, there there was the companion eep, which is unfortunately still marked as draft, even though it is you know long out, and it is the e2364, and uh this is basically the heap that is actually using the fork identifier. So it's like it extends the protocol to uh also have the the actual networking protocol to also use this mechanism. But let's talk quickly about the ev2124, so.

B

The situation was as follows: so um in the ethereum network protocol since the very beginning there was this concept of the network id and the network id is a number which is which identifies the chain, and if we look into the specification, then uh we will basically see that what are the defined network ids.

B

So I will start the screen share now and then we can look at the thing together.

B

Can you see my screen now? Okay, so here is the eep. um Actually, when I was talking about the the other, ebook is also showing it. So this is the this is the this is the eep for the fork identifier.

B

This is the eep for the network protocol extension using the fork identifier- and here is the specification of the e networking protocol, which is the protocol that is spoken between the nodes.

B

So um what you can see is that the very first thing that the nodes say to each other when they connect, is the status message and inside of the status message we have the network ide. I have.

B

And then the network id is actually, you can see some common network ids here. So the network id 0 was used for the olympic test net, which was pre-mainnet launch.

B

One was allocated for the frontier network, which became the main net and then further network ids were allocated for the official test nets. For example, the number two was used for the modern testnet, which is long dead. uh The number three is allocated to robson, which is still in use, even though it at this point is not useful, but yeah people use it anyway, and uh the number four is the rinkeby network, but actually the.

B

Chain id not network, and it shows all of the different uh network ids, which I use and you can see there are quite a lot of them. So basically, when people create alternative ethereum networks, they usually choose a network id and they are all listed here.

B

So that is the network id. um The problem at the time was that for when there was the dao, the the network already had the network id and when it was forked, uh the other network actually had the same network id. So the at this point the network id was became a little bit useless for distinguishing.

B

You know the actual ethereum networks, because there were two networks with the same id and um we were thinking about it at the time and then we were kind of thinking like what can be done about it, and then we kind of thought that it would be nice to have some kind of dynamic network id and the dynamic.

B

Number like this, it should be like a short number and by short I mean it should be smaller than 64 bits, and this number should somehow uniquely identify the network without having to explicitly configure it before, and then um we were thinking about it and it is, it is actually not non-trivial um to figure it out, because the the the um you cannot distinguish the networks by the genesis block alone, because there are some networks which are created using alternative like basically there can be many chains originated, it's not just the genesis block and um the network id is also not fully sufficient, because the network id is just some number that was decided once and if the chain is forked later, then you still have the same network id.

B

You can change it then, but it's like it's it. It doesn't. The network id is not part of consensus. So, technically, if a fork is created, it could change network id, but at the time it was also really. It would have meant that, basically, if we wanted to actually like you know, do it for every fork, we would have to assign a new network id for every four and then configure it into the clients and it and there could still be clutch, so it didn't really work.

B

So what we ended up choosing is basically this idea that um the the the the fork identifier is a number which somehow contains the genesis block hash and the block numbers of all of the scheduled hard forks that have occurred in the network and the reason the way it works, and I can quickly show it here so basically, um uh regarding the forecast, so the fork identifier, it has two parts, it has the four cache and the fork.

B

Next, we will ignore the fork next for now, the fourth hash is uh using the crc32 checksum function, and the way it works is that the fork identifier for the current head of the chain, according to the node, is defined as the crc2 of the genesis hash and then basically inputting into the crc32, the the block numbers of all of the scheduled hard forks that have already occurred in the chain, and um so basically, here in the example you can see it.

B

The initial forecast is just the crc 32 of the genesis block hash and then um the further four caches uh for the chain are basically like. You know it's the csc32 of the genesis hash and into that goes the number of the first fork, which is the homestead fork, and then here we can see we can compute the next four cache by basically taking the same thing again, but appending the next block number. And this in this case it is the dial for.

C

So when you say block number, are you saying, like the block number at the fork.

B

It is the block number at which the fork is activated, so in ethereum, usually the forks they are scheduled using eaves.

B

So you can see it here, for example in the eip686, if this has a high number, because it was created uh retroactively- and you can see it here- that basically, this is the block number of the fork on the main net.

B

So this is the activation block, and then here you can see it that this number it goes into the into the checksum like this.

C

Yeah and this goes and then how to keep track of, like which um four caches there were previously or is it just no.

B

So basically, um what you can do is every node computes the fork hash of the current head of the chain, and this is basically its current forecast. So the every node has a single fork identifier, and it is basically the fork hash containing all of the hard forks which have already activated at the current block, but it changes over time. So, for example, if the node is sinking then initially its forecast is the genesis because no hard forks have passed, but once it sinks beyond the block.

B

uh Beyond this block the it's like 1 million 150 000, then the forecast will change to that of the homestead book.

B

You know what I mean interesting yeah so um and because the the purpose of the fork id is to validate whether the node is actually compatible, and in order to do this, there has to be this validation rule, and you can have it here, as you can see it here. So basically, the for the the way it works is that using this construction, you can generate all of the valid four caches so, and this is in fact what the nodes are doing.

B

So basically, if you want to check if some node is compatible and with you and you are at the current head of the chain, then you just basically compute all of the checksums for all of the forks which have already activated. If the node is one of these four caches, then it is compatible because you know, for example, this forecast is also valid because it is like you know. The node is just you know at the genesis block at the moment.

B

You know because it's not synced yet, but it's still compatible because you know it's it hasn't. It has not passed this cork yet, but if the node, for example, then activates the homestead clock at the different block number, then its four cache will no longer be part of the set of the valid four caches, and so it will not be compatible and you can see there's a big table in the.

B

If that also kind of explains this, these validation rules and like whether it is you know like okay, to connect to the node or not, given the forecast that it is advertising and yeah- and you can see the explanation here, for example, if the, if the, if the, if the local, uh if the local four patch and the remote fault hash, are equal, then obviously it is okay to connect because they are both string to the head of the same chain right.

B

But um we will ignore this part about the fork next, but um yeah. You can also kind of see that, like sometimes yeah, there are some cases here where it's like. You know like these cases it it. You just have to check the table. It is this. There are quite a number of situations that can arise depending on, like which four clashes are, you know like available locally and which ones are not but uh yeah. That is basically it, and uh we can also go over the fork next, so the fork.

B

Next is simply the block number of the next fork, and the next fork is basically the next fork. According to what the node is thinking, what the next fork is so basically, if the node is currently in the homestead uh state, and uh then the next clock will be the dow fork, for example, and this information is also used during the validation it can be used to detect if the node has upgraded or not, or you know,.

C

What, and why would you want to connect to a node that hasn't fully synced yet.

B

um Well, it's not not so much that, like the node, you wouldn't necessarily connect with this node, but the node might still want to connect. You.

C

Yeah and that's necessary because well.

B

They'd have to think you know like.

C

Oh okay, to explain a bit. The ethereum network works where um you start out with nothing or maybe the the genesis hash you connect to the network, and then you download, um like the history of the blockchain right yeah.

B

C

B

B

Yeah, so basically yeah, so in order for basically the the purpose of this of this. For so the fork identifier, it's important to understand the focus. Identifier is a very abstract sort of thing. It is a um the fork. Identifier is simply like this, this 32-bit number, which can be used to to detect if, um if the node is comp, if two nodes are compatible, but this eip, the eip2124 doesn't actually say anything about.

B

You know like how exactly this should be used, it's more like an abstract idea, and then we actually have the other eep, which is the 2364., and this integrates it, for example, into the networking protocol, and this is actually also part of the of the protocol specification.

B

So we can just check it in the protocol specification and, as I explained it in the beginning, um there is the status message which is sent with when the peers first connect. So basically, when the peers connect, they first send the status message and you can actually see that part of the status message since the east protocol version. 64. Is this fork id and then so? Basically, whenever two peers connect to each other, they can immediately determine if they are compatible or not.

B

Based on this fork id which the other side is providing- and you are also providing in either side may then disconnect because they consider it incompatible.

C

Okay, that makes sense so, if you were to um like say, start off at genesis and then, while you're sinking you get up to whatever the homestead um fork was like. Was your.

B

Forecast, it will change all the time during sync yeah.

C

Okay and that's like automatic, I'm assuming yeah.

B

It's automatic is this: this is the the purpose of the fork. Id is that this is automatic, yeah yeah, I can show you in the code.

C

Oh, no, it's okay! I'm just I'm just trying to to verify the full fleek flow. So how do you prevent or what what's the negative impact of if you had two nodes connect that were incompatible so.

B

Basically, the thing about this is that I explained it a little bit in the beginning. So after the dow fog there was this unfortunate situation where there were two incompatible blockchains with different fork walls, wars, but they were both.

B

Basically, they both had the same genesis, block and the same network id, and when this situation happens, there will be a lot of useless peer connections and you will only find out if the peer connection is is, is that the pure connection is not useful um when the node is sending new blocks, which is uh which are, you know like invalid?

B

So, basically, what you have to understand is that for the foreign ethereum node, when it receives a block, it will always validate the block, because the block may actually you know, be valid and the part of the chain. So when you have many useless peer connections which are relaying invalid blocks, it just creates a lot of additional work for the node to verify all of these invalid blocks. So it's like. Basically, it's just wasting the computation. You know, because you we already know they are not compatible because they have different fork blocks, so it it.

B

It actually doesn't really make sense to. You know, try and sync it anyway. You know what.

C

I mean that makes sense.

B

Yeah, so this is like this is like kind of the goal. It's an optimization it's supposed to make it so that basically the nodes when they are when they are talking to each other, they can already know before, if it even makes sense to you know like download all the blocks from the other peer, because the other it's actually at the current time.

B

Actually it it's it's. It turns out that uh in ethereum, classic sometime after the dow fork, they introduce their own version of the scheme.

B

I have no idea what it's called or it's a bit different, or maybe they just simply change your network id to make this problem disappear on their side, but um basically um like a short while after the dow fork, it kind of turned out that, like you know like the the chain that executed the dow fork, which is now the current main net, this chain um has the higher proof of work value. So in practice the ethereum mainnet nodes.

B

They would not sync from the ethereum classic nodes, because the advertised proof of work weight was just much smaller, you know so, basically they would not. They would never follow the ethereum classic chain, but for the ethereum classic. This mechanism is actually very useful, because if it wasn't there, then otherwise, basically the ethereum classic nodes would always sync the ethereum mainnet up until you know hitting some block where a transaction is performed. That hits one of the accounts that were affected by the dow fork.

B

You know what I mean, so basically they would just always think of the wrong chain. First, even though it's you know not compatible and then it would have to.

C

And so just to kind of, like, I guess, uh like repeat what you said back to you, um you're saying that that problem existed because the um like, in this case the forecast between um the genesis and hope instead would be equivalent, which would just be the id but um and and then that would cause issues. Because you don't know like the exact thing is. Is that what you're saying.

B

No, mostly, what I mean is that okay, so what you have to imagine is that if you have two blockchains and they are both based on the proof of work- and they are both- they both have the same genesis block and they both have the same network id and the network id is not the fork identifier. It's this other thing that I explained in the beginning that the network id has always existed even before this.

B

So um if you have two, if you have two blockchains and they are basically the same up to a certain block where, on on on one of the chains, some fork happens and the rules of evm execution change and then on the other chain, there is no such fork and the rules of the evm execution do not change.

B

This creates two blockchains right at this point in time, because one is continuing with the new rules and the other one is sticking to the old rules and then basically the but the node. It doesn't really know anything about the content of the block before it has successfully imported and processed the block. So the only way by which the nodes first decide which chain they should sync, is simply the proof of work weight of the chain.

B

So they will simply look at the block, headers and say: oh this chain is heavier. I'm going to sync this one and then during the execution of the chain they will find out that the chain is actually incompatible so because, for example, you know like because some fork happens, which the node is not prepared for, or something and then so. At this point there will be a huge reorganization of the chain back to the point where they were where they split up, and then it will follow up the other chain.

B

But it's actually when they're when they're a long-range reox, it gets very, very inefficient because it you know, will con. It might even continue switching back and forth between the two chains, and it's just it will basically lead to a non-functioning network. The network will eventually probably work out, but it's kind of like not it's. Just not a very nice experience to be stuck in this like state where there's a competing blockchain, which has you know higher proof of work, but is invalid. It's just kind of it.

B

Just messes, with the logic with the sync logic of the nodes.

C

Yeah, no, that makes sense. uh My only other question then, would be um like how does the forecast address that.

B

So it addresses this because the forecast recognizes that there is this concept of the fork block number and if there is a fork, a hard fork is scheduled on one chain, but not on the other chain. Then at the block, where the fork happens on the chain, the fork hash will change.

B

So from this point onward in the networking protocol we can already when, when the node, when the peers connect, we can immediately decide that this video connection is not going to lead to a successful sync, because then, because the two peers are trying to swing two different blockchains, do you? You know what I mean.

C

Yeah, I I do um I'm just trying to sort of like explain it in a way. That's or I'm trying to reiterate just to make sure that I have it fully clear, um and I assume then so then all right, I'm gonna, try to walk so four cash zero.

C

The genesis like that would connect um up until it's synced until or if it's trying to get a block, that's lower than whatever this homestead block was right.

B

Yeah so when the node starts initially, it starts at the block zero. So it is at the genesis block, which is the block zero.

B

So the for cache, the local for cache of the node, is the is simply the checksum of the genesis hash and then, as the node is syncing, and it is importing more blocks at some point.

B

It will import this block, which is the block number 1150 000, which is the homestead block, and then, at this point the fork id of the node, the local fork, id of the node will change or the local fork hash of the node will change, and it will change to this one, which is the checksum of the genesis hash, and you know added into this- is the block number of the homestead fork and then, as the node is progressing further and sinking through the next four block.

B

It will add this block number to the checksum as well, and it will continue doing this until it eventually hits the head of the chain at which point you know like you know like it will just keep doing this. You know but, like you know at some point, it will hit the state where, like it has swing through all of the passports.

B

At the moment we have a whole bunch of forks, so um it will go through like when you are thinking right, so you will go through the homestead vlogs spurious dragon fork. Tangerine whistle fork, byzantium fork gal for constantinople fork, istanbul for petersburg fork, glacier fork, berlin fork. You know all of these forks it will they at some point. They will all happen during the sync.

B

You know, yeah.

C

B

Then, each time it happens, the four cache will be updated. The local for cache will be updated.

A

Okay, so I have a question uh related to three-way forks, like uh as it is mentioned in the abstract section uh like this eip. This two one, two four proposal uh does not give a clear separation of three-way folks. So can you elaborate what is this three-way fork and like? If um is there an example that might help people to understand.

B

Yeah pizza broke this um so yeah, so I mean it's kind of obvious right, so this scheme is based on the block number.

B

So it means that if there are two conflicting forks scheduled at the same block number, then this scheme will not work, and this is because the the nodes will have the same forecast, because the forecast doesn't include anything but the block number of the fork.

B

So it's like if at some point you know there is this. There is this thing where you have uh where you have two forks scheduled at the same block then, like I mean two conflicting forks, but this is very rare and I think the situation is very unlikely to arise in practice. So we, when we could see this three-way fork situation if we had.

B

um If, for example, there was a- I mean in the current ethereum eip process, things are generally agreed upon in by some committee and then everyone, you know kind of you know, implements the changes exactly as specified and it's all tested and then the fork activates at some future block.

B

So usually, the implementation of the fork eips happens first and then once the four eips are implemented, and they are all they are all tested, then the activation block number is set, but if there was a very contentious heart fork right and then you know like someone would actually schedule like if some part of the ethereum community would feel that this hard fork is not acceptable to them.

B

For example, then they could create an alternative specification for a different hard fork and they could even schedule it at the same block number and if they would do this, then there would be like three ways to go. You know you could not fork at all, because the client was not updated and doesn't include the new code for the fork or the client. You know the the user could update to one version of the client which implements the fork a or it can.

B

The user could update the software to some other client, which uh you know implements the fork b and then so. This would lead to this three-way separation, and this eip, like the fork identifier, cannot handle this. So at this point we would have the situation again where the two chains, the 4k chain and the fourth b chain- would be competing.

B

But yeah, but it I think it is unlikely that this will happen, because why would you schedule it at the same block? It doesn't really make sense, I think, like usually people either want a fork or they don't want to fork. It's not like. They want one fork or the different one.

B

Okay, so it's kind of yeah like it's. It hasn't really happened yet you know the situation. So it's it's more like hypothetical. I just wanted to give a quick overview, so these erps were implemented a long time ago, and you can see it here. So um the 4k, the fork identifier itself, was implemented in go ethereum.

B

The implementation was submitted on 8th july of 2019, and this is yeah just a little bit after the eip was created, so peter himself implemented it um this. This is the original pro request that implemented and it was created. It was actually added to the one line, the to the guest version 190. So it's quite a long time ago, and um the one part of this implementation was also the implementation of the of the enr field, and this is something that I'm actually not sure.

B

If it is it defined, in the same in the same eep,.

A

Are you talking about seven seven, eight, maybe.

B

I'm just checking if this, if this talks about the enr at all, it seems like it does not talk about the enr entry yeah is there? Is there? Maybe we made it even yet another eep for this.

B

No, I think no, we didn't really make I'm actually not sure. um I I always thought it was part of this 2124 eip, but it doesn't really matter so. Basically, this is the specification of the networking protocol, but uh in the last people, if where I was present, we were also talking about the enr and in fact you can see it basically that uh we have the enr entry which at the moment, contains only the fork id.

B

So this is something to um yeah and it says it was proposed in the e2124, but I cannot actually see where exactly it is proposed, but it doesn't really yeah anyway. So um what this means with the enr entry is that this information about the fork at which the node is currently you know compatible with this information is also part of the discovery protocol.

B

So, basically, when the node is discovered in the ethereum dht, then it is also possible to avoid connecting to nodes which are known to be incompatible, and this can be done by simply checking whether the node record of the node contains a compatible fork id fork identifier.

B

Does it make sense to anyone saying it like this.

A

Yeah that totally so uh I I was just wondering about one specific uh case. I don't know if it may, if it is possible at all or not like anything different uh test nuts and like they have their uh train id. So is it possible that by any chance, I I don't know, I'm not aware of any situation like this has ever happened in past.

A

Is it possible that by any chance, if we get the same block number for any test net as well as for the main it, and then that may create a situation where they will end up with a three-way fork.

B

Well, so this is why, for example, we also have the genesis block hash in in the fork. Identifier and the genesis hash from the start differentiates the test nets from the mainnet, because probably the test net will not be created using the magnetogenesis block.

A

B

So yeah, so that in practice I mean, if you want, we can look at I'm actually, not sure like I mean how how to how to really demo this um this. So this mechanism is kind of kind of you know like it's an again. It's like it's an optimization that we have implemented long time ago to like make sure that the like invalid connections between nodes do not happen, and what I can say is that this this it has.

B

This eip has turned out to be very useful because with every fork that happened since then um we had the uh like it has prevented. You know like these useless connections from happening, so this it to this day. This evil continues to work. It's not just for the dow fork. So, for example, when the berlin fork, I'm actually not sure that the berlin already activate on magnet or not. I don't know.

A

B

Okay, but basically so um when the berlin fork will activate on the main net, for example, it is. You know like at this moment that, when some of the notes have will have updated to it, we can actually check this. Now I mean it's not a good, uh not the best way to check it, but, for example, we can just check the east stud.

B

It always happens right with every fork that um some people do not upgrade the node for the fork and then yeah. For some reason, the x-stats is not doesn't work for me, so we cannot check it.

B

Basically, um sometimes it happens that um the people do not upgrade the software in time for the fork either because they forget about it or some other reason, or they can't upgrade yet or whatever, and then basically, this erp ensures that, like in this situation, uh the the the the node like the it creates a bit of an isometric situation right, so basically your node it will, it will just be stuck at uh behind, but it can still connect.

B

You know so it's like, um but at the same time, if you know like, uh if you upgrade it to some totally different version of the software or something or you you know render ethereum classic or something, then it would like prevent the connection. So I think it's kind of something that it. It really works for us this eip and it it hasn't, really created any problems, but it has created some benefits, so we we feel much better about.

B

You know the the activation of the forks, because we know that this mechanism is there and it will ensure that you know, like the invalid connections, do not happen all right. So it's kind of it's something that you know just makes it a little bit easier to. You know be certain that the fork will actually work.

A

So I have like a um question uh that is obviously not directly related to this proposal, but, uh as you have mentioned about eip2364, that is uh each sixty. Four four kinda extended uh protocol handshake right, so this proposal is extension of 2124, as I see like by specifying how the fourth id should be exchanged between the peers.

B

Yeah, this is yeah, so it's this is only for you can see it here. So it's like the specification is not very long and basically, what is what happens here is that you have.

B

You have the fork id generation and validation which you need to implement in order to make this work, and um you need to implement the like.

B

You need to add the version number 64 to the eth protocol to implement it, and then the status message is changed to include the additional fork id and then the idea is that when the status message is received on both sides, then they must both validate the remote fork id and disconnect if it is incompatible, but the actual compatibility rules are not defined in this e because they are already defined here. So here are the rules and you just have to run these rules for every new connection. That's the idea, at least so.

B

The implementation of uh of this you can see it here. This is, it was. It was added on 30th october uh 2019, and it's not a very big for request. I mean it's about it's 300 lines added, so it's not a lot, because if you, if you check it in diff, it basically does exactly that. I mean it changes some parts of the of the of the like. Usually the the protocol version updates in go ethereum.

B

They can be a bit long because uh some stuff has to be changed, but it's really mostly about and in this pull request also the ethereum protocol version 62 was removed at the same time.

B

So I don't know uh that. Would there there's a bunch more changes here than necessary, but basically it's very simple, and then you know some stuff is just for you, like unit tests. You know like checking that they are actually not uh that that the connection is rejected.

B

So the the implementation is is very tiny, and this is because really this eip just says you should have the fork id as part of this like handshake between the peers and they should validate it, but the validation was already implemented when the fork when the fork identifier was implemented. So it's not like uh the. It wasn't really really like a very big change.

A

Right so my question here with you is about the uh you know: kind of the process part like for each 63. There is uh no eip right. It is maintained in that p2p repo. So I was curious to understand like what are your thoughts on get deciding to go.

A

The path of eip standardization for this particular thing like not implementing adding the four card directly as a field to the existing repo and going by the standardization process.

B

Are you asking about the eips for the youth.

A

This proposal, uh the eip two three six, four, uh that is four caddy extension for uh the eip two one.

B

A

So this, uh my question is like why we are not directly updating it in the repo directly as we did it for each 63. Instead, we are going the path of eip standardization to add the fourth id field in uh in the code base.

B

Well, so, at the time when, when this was written, we were kind of thinking that like it makes sense to like, and we still think this today, I I think it makes sense to announce changes to the east networking protocol using the eip and uh so, and the same actually happened for the protocol version 65, which was added like a little bit later. Actually, I'm not sure yeah, it was added.

B

In january 2020 we moved on to the east version 65, which is after this fork id, and now we even have the each version 666, which was in which is also implemented as in as part of like guest, one version 110..

B

So I think it makes sense to to talk about the to to to talk about the protocol changes as eaves because they, while they are not um it's not as critical as like, you know, for the consensus, but it still makes sense to have some.

B

You know some place to announce these changes and we can make the changes in the specification, but, for example, for the e66 we haven't made this change in the specification yet so, for example, in the in the specification we are still in the version e 65, because I haven't updated it yet for the 66, but it will eventually be updated for the 66 as well. So it's just kind of something that I I feel like it's just like. You know good practice to make the eip for the east protocol changes as well.

A

Right, I asked this question because, uh like last week we were discussing eip1474- that was an interface cip for ethereum rpc, and there was some suggestion on the process improvement part so because these proposals are not core proposals and they do not require client consensus, so we were trying to figure out what would be the best way to keep these specs updated and if it is by following eip standardization part, that's fair enough. If not, then we can figure out some other way so yeah that was it moving on the implementation part.

A

You mentioned in the beginning that this eap2124 has been implemented by most of the clients. So I was wondering by any chance if you have visibility of the repository of the client implementation or maybe how much it is implemented, is it totally implemented?

A

So what is the status of it or if we can add this implementation to the proposal itself like in the proposal? As of now, we can see only the link up available for get get implementation and no other client. So is it possible to add more clients, implementation there.

B

So um it is implemented in open ethereum. uh uh I don't know since which version, but in the latest version 3 2 3 version 3.2.0, it is implemented. You can see it, they are sending the fork id. So it's okay.

B

It is implemented by nethermind.

B

It's also implemented by bisu.

B

And it is also implemented by like by go ethereum.

A

Right so all major classes- oh.

B

No, this is the wrong test. Wait one! Second! uh Here we go yeah, and here you can see also that goethe implements uh version. 66 and uh the other clients don't uh implement 60. uh I keep clicking the wrong thing, I'm so sorry um yeah, so they don't, they don't implement it yet so this is this website is.

B

This is the dashboard of the hive testing tool, which uh basically just runs all of the protocol tests all the time, and we can kind of check it and we can see if they, if the clients implement something or not, but as far as I'm concerned like if go ethereum be soon never mind implemented, I will consider it to be like fully implemented.

A

All right, so what did it do like logical to add these links in the proposal itself, because, most of the time we try to get the the list of clients which I have already implemented, and it seems that most of the uh clients have already.

B

Yeah I mean this this I wouldn't link to this because it just changes all the time and we it's not like the the test reports here. They just change like every couple days and we also throw away the old test reports from time to time. So it's like the links will just be dead. Eventually, it's like this is an ongoing thing and just you know, these test results are from like yeah. It looks like some somehow it. ah The sorting is wrong, but the latest test results are like from from uh from today right.

B

So it's like, we will eventually remove the old test results and then the link will not work anymore, but we could link to the pull request. For example, I mean we have the we have the the pull request here and then we can check it. For example, in the um in open ethereum, um it's a it's a it's a very good question. If.

B

When it was actually implemented, I guess it was implemented as part of the e364, so we should probably.

B

Yeah, so here we go so there was one which was rejected and one was accepted so they implemented, but they implemented it uh last september of last year, so yeah yeah, I mean actually it was resubmitted resubmit of the other implementation, but you can see that people eventually implemented this, but if they don't always, they didn't implement it immediately. I don't know for all of the clients when exactly they implemented it, but I mean, as of now, it's all implemented, so this actually contains the fork id as well yeah.

B

It was it they added it here, so it was. They implemented the fork id as part of this e64 change, which is okay. I guess.

A

Yeah right, so I have one last question for you: uh it's about the status change. uh So, while going through the proposal, I found that one of the biggest motivation for this proposal is to maximize the utility of the public nodes to ensure that resources are not wasted and tasks that are not of much importance does not consume resources.

A

This particular proposal this was proposed in 2019 at the time of istanbul.

A

In your mind, what could be the possible reason for the delay in moving this proposal to reach the final status? I know the implementation was going in the back end, but I was trying to understand any blocker if there are in terms of process that you would like to mention.

B

uh Well, so uh I said it last time about this about this already, so when we was when we had the call last time so I mean I just think basically that nobody really cares about these eeps. You know so it's like. um I think these eats are most valuable for, like you know, people for the client implementers because they can check it exactly.

B

uh What's the uh you know what's new and what what they could, what they could implement and in the past we also brought these things up in the all core, devs call, for example, and when we had some ideas for network protocol changes, we just announced it in the awkwardness.

B

Personally, I don't really care if you know like what the status of the eep, because we will just basically this process has mostly been a process of just negotiating it uh between the authors of the eep. In this case, it's us, like I mean me and peter and the client implement us. So basically we just go to the client implementers and you know like annoy them about it until they implement it and uh once it's implemented, it's like. I don't really like. I mean I don't have the authority to change the status.

B

I think these ips should all be final because they have been implemented for a long time and they are all tested and they are very useful. So, from my point of view, I think they are pretty much all final, but, um like I mean the ones that are currently in the review, but at some point it was decided that we're dropped. You know like these things are dropped. They're, not even reviewed they're like you know, just stuck there in the draft, but it doesn't really matter because since they are, they have already been shipped.

B

I think someone wanted to change so, for example, for these hips here they would change. The last call because I said that you know like they already implemented and then they said yeah formally, we would have to go through the last call stage. uh I guess the then you know someone moved it to the last call.

B

I have received zero feedback during the last call, so now they are just stuck in last call I mean eventually, you know. If I get to talk to someone who has the authority to change the status. Maybe you know next year they will be changed to final uh when the review period is already like one year over.

B

A

uh Yeah, I think um that is definitely an issue like there are so many proposals which are in one status and has been stuck there for just like forever. uh We.

C

A

Like uh find those proposals and talk to authors and just keep it pushing towards the next status, so just for your information, the last call status has already ended, like in september itself, 2020- and uh this is up to the author. uh They can when they find that the proposal are ready to be reviewed. They move it to the review status and from review if they think that there is no major spec change is expected in the proposal.

A

The proposal can be moved to the last call and once the duration of 14 days are over, they if they find that the proposal is like expect enough, and it does not require any final change and it can be moved to finance any.

A

Anyone like author itself can create a pull request to change it to the final status.

B

Okay yeah, so maybe I should just change it to the final. Then that's, okay. I can.

A

B

So forth, yeah.

A

And for other proposals that we discussed in the last meeting, eip 778 and more of the similar proposal, as you are showing on the screen like there are a few which are still stuck in the drop, so we have to keep pushing it to one status to another if it is already implemented. I don't think there should be any reason for delay uh in moving.

C

A

Status to another status, so yes, this is completely uh up to the team.

B

Yeah, so I think basically for example, it doesn't really make sense that these two are in draft, but this one is in review because uh the one that's in review is like the later version. So it's like. If this goes in then you know the other ones are also. You know accepted it's like it doesn't yeah, so I mean I think so. Basically, what I think should really happen is that these two things here they can move to. um They should basically just probably the next one would be last call like formally.

B

The next status would be last call, I don't know uh they could also go straight to the final. I don't really know and then with the e66, it's kind of okay that it's in review, because we just implemented it and it's you know like I mean it's, it's very useful, but I don't think there will be any further changes to this. To be honest, but uh yeah I mean it's, these are okay. I mean these can be in review. It's okay, they can. They can move to the last call like very soon.

B

I guess because you know, and then uh actually so both of these are implemented, so they probably they should move into the last and then these the this one specifically the 1459.

B

I don't care if it's going to be in draft forever. You know it's not really something that requires.

A

That has been superseded by some other proposal. We would want to put the status of withdrawn so that we can show the correct status of any proposal. So if you think that 2481 that has been superseded by anybody else- oh sorry, that is the latest one right. Sorry.

B

Yeah, no, no, no, it hasn't really been superseded. It's more like what I mean is that these two they were like past protocol changes. They have been live on the network for a long time and then this one is, you know, not live on the network for a long time.

B

It was actually you know, like only very recently, was it even activated, and we really hope that by the end of this year it will be implemented in all clients, but, as I showed it earlier at the moment with the e66, it is only available in the go ethereum so go. Ethereum can do it with the protocol version 66, but the other ones cannot do it yet.

B

So it's like, I think, it's okay, that it's in review, because when other clients implement it, they might find some issues in this and they might want to change the specification further. So it's probably okay that it's still in the review phase, but the other ones they cannot. They cannot change anyway because they are already implemented and we cannot retroactively change the spec because, because of formal reason, so it's like they they will just these are practically final.

B

You know, but then this one, it's okay that so it doesn't really make sense that you know like they are in draft, because this one is already in review and yeah, never mind the it's it this this. The situation is just you know like a little bit messy, but I agree. I can move these eips to the to the final because you already said, since the review has already passed, uh it's fine, we can. I can move it to the final and yeah.

A

Right now, this is completely up to the author. It's just that we are trying to. You know, uh provide more information around. What's going on with the process, we are looking into the standardization process and uh trying to you know, put all the eevs in the appropriate status that is kind of clean up of the repository, because it's too much like cluttered right now so yeah all right.

A

I mean this was really great uh thanks felix for joining us today and talking about these important networking layer proposals, I feel it's important to talk about different eips to let the world know that ethereum improvement proposals are not just erc's and core proposals that they are much more than that. I mean it may not be visible from a very high level, but the contribution at the networking and interface level should not go unnoticed, um as we have been looking into the eips.edm eips.edum.org.

A

There is just a fact that I would like to share with you all out of 352 eips that that are listed in the eips.ethereum.com at the moment.

A

Only 11 eips are the networking category and only three eips have made it to final status, so we already have discussed that we might have to look into the change of this status and these are already implemented. We would want to see those proposals into the right destination on this note, for all our youtube viewers, thanks for watching there are other related proposals for networking that you could be interested.

A

You may find them on eips.ethelium.com and if you have missed watching the episode on eip 778 enr that we did earlier with felix, you may follow the recording at penny youtube. I hope we have covered most of the questions related to this proposal. But if you still have any question that we could not answer, you may ask that guest we'd love to hear feedback and improvement suggestions.

A

Do let us know which eip would you like to see in future episodes if you like, the episode hit like and don't forget, to share it with people of similar interest. We have many more interesting proposals coming up your way, so stay tuned keep watching, keep sharing your love with ethereum cathartis. This is all of us signing out.