Ethereum Cat Herders PEEPanEIP, 7 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Peep an EIP #14: EIP-778 with Felix Lange

Description

EIP: https://eips.ethereum.org/EIPS/eip-778
Discussion: https://github.com/ethereum/devp2p/issues/43

Follow guest on GitHub:
Felix Lange @fjl

on Twitter
Pooja Ranjan @poojaranjan19 | William Schwab @William94029369 | Brent Allsop @Brent_Allsop

Peep an EIP episode #1: Writing an EIP - https://youtu.be/Vnu4m4bBqCs
Check out other exciting EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2

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

A

Hello and welcome to another episode of peep any and eip focus series. I'm your host pooja ranjan and today we are going to talk about the eip778 ethereum node records. Enr eip 778 is a standard track. Networking eip according to the abstract, provided in the proposal. This defines ethereum node records and open format for p2p connectivity information.

A

This proposal is currently in the last call status and has already been implemented in some of the clients. Along with the author. Today, we are joined by david from the basu team, brent and william from the ethereum cat hurdles. So without further ado, let's welcome author of the proposal. Felix lang, thanks for joining us felix, please share a little bit about yourself uh before we dive into the proposal.

B

Yeah yeah right, hey yeah, so I've been working on ethereum since uh yeah the beginning. I.

B

B

The about the p2p networking and stuff, but we kind of stopped doing those- I don't know mostly because I feel like people were not so uh not weren't, always so interested and I'm not the best presenter. So yeah, I'm not a very. I don't know like public person, I guess but um yeah I don't know, but I mean I'm really happy to be on this thing here and you know just talk about my stuff, so yeah um yeah, that's really about it.

B

I mostly I work on go ethereal most of the time, so this is like you know. If you've ever interacted with me online, it's probably been through the go ethereum uh repository because yeah, I'm I'm very active there um yeah. So uh maybe a little bit. I don't know if my slides are already like visible to everyone.

B

I don't know. Can you confirm? I did share my screen, so I guess yeah. We can see.

C

B

Cool so yeah um I made some slides um basically so about the seven seven eight, it's kind of interesting, because um yeah I should have started with this slide first, so I'm just gonna go to the second slide straight away.

B

It's the um basically one thing to know about eat 778. Is that it's really old, so um I submitted it in november 2017, um which is like three years ago, and um we submitted, because uh when we were working on the early version of the discovery version five um for the light client project, which is still ongoing, as is the discovery five project so there both of these projects are still ongoing.

B

uh But when we were working on that in uh like early uh 2017, we kind of noticed that there's this problem, which is that uh in the discovery version four, uh it's the the protocol that all of the uh nodes use to find each other on the internet.

B

um The problem with this protocol is that it doesn't really contain a lot of information about the nodes.

B

So it's kind of weird because it's supposed to be this protocol, where they can all find each other and they can, but the only thing they can talk about is you know like what's my ip and stuff, and um you can see that here so basically, all the information that can be relayed is this information, and that was just a little bit like it wasn't really enough because, like especially for the like client, we just we just need like a lot more metadata to really assess if this particular node is like a good candidate, and it's always been an issue, especially with the like client, that most nodes are not like client server capable.

B

So it means that if you find a node in the discovery it like the chances that it actually has, the less server enabled are pretty small. So it would be super nice to just kind of know. You know, does this note, have the alias server enabled or not, but there's no way to tell if that's the case, uh using the usb protocol and then we kind of started thinking like you know.

B

What would be a good way to do that and we didn't just want to add like a single flag that says: is it elia server or not? And so this question kind of sort of became enr, which is a general format for saying such things about nodes in the discovery and um we actually the enr, is actually deployed. So the fact that his last call is kind of weird, because I feel like you know it's just you know it's it's it's in active use and it's been in active use for uh quite a long time.

B

So um yeah, I don't know with the networking eips. I don't. I think nobody really figured out yet how to design the status properly because they are not included in the hot fork or something they just you know get shipped and so basically yeah the enr is live and we are using it and the first real use was in the dns discovery, which is also live and in use, and that is the eip-1459.

B

But we're not talking about that one today at least not so much, but that was basically the first time we really started using the the the enr in eth one and uh notably in the discovery version 5, which is not used by f1 at this time, but it is used by eth2.

B

um This one actually uses enr as the native format, and uh so they are, you know happen like basically, it deals with eonars like all the time, whereas in the 8th one. The enr is more like this, like side thing that some notes can do and but it's not mandatory in each one anyway. So um yeah, let's get back to like. What's the idea behind the note records in the first place, so the a good analogy for the node records is that it's like business cards for uh notes right.

B

So it's like when you meet someone in real life and you're. You know at a conference or something probably they're going to give you a business card and on this business card is going to say, hey. This is I'm, I don't know adam something and here's my email address and use my phone number and you know I'm a I don't know venture capitalists or whatever you know, people put on their business cards. Maybe it has a logo on there.

B

I don't know- and that's like kind of the analogy within ours is like this: it's a place where um you can put information about the node, but also- and it's quite important- and I forgot to put it on the slide- um it's um size limited. So basically there isn't like an infinite amount of space. So if someone would give you a two meter by two meter business card, you wouldn't really be able to put it in your wallet or something so. Business cards are usually pretty small and it's the same with the enr.

B

They are very small and actually they are 300 bytes in size and they cannot be larger than 300 bytes. So this is guaranteed by the specification and inside of dnr. You will find network connectivity information so, for example, you have the ip and port and public key and stuff in there, which is very useful for for that. But um you also have protocol specific metadata. For example, you have some metadata which is related to the if protocol- and that says you know like which particular fork of the ethereum blockchain you're on which is very useful.

B

So you can, if you find a node, you can immediately check if it's on the same ethereum blockchain that you want to be on with your node. So that's like one of the things that it can do and um yeah. The purpose of these is not not like it's relaying these, but it's not limited to the dht. So we use the dht system for relaying nodes most of the time, but um with enr. Since it's supposed to be kind of a standalone format, it can also transcend systems.

B

So it's like you can use in you can use. Enrs is like an interchange format. If you have more than one discovery system- and we will actually see an example of that in yeah- pretty much now so, um but let's just look at the let's- just look at the uh eonors first, so this is what an iron r actually looks like.

B

This is the text format, and this is the one you're gonna see most often and the text format is really just yeah, the string enr and then some base64 encoded binary data and the binary data is rlp. So you can see the equivalent rlp structure here.

B

So this is what this looks like, and you can see that in here there's a signature which I've truncated, because it's very long, then you have the sequence number, which is also quite important, and then you have key value pairs which are basically the key and then there's the value and then there's another key and another value, a key and a value and so on, and uh it's maybe easier to look at it in the like decoded form. So this is something that you can print using some go ethereum command line tools.

B

You can see that this node record, which I've shown here it contains this information. So the information is it has this ethereum protocol metadata. It has uses the identity scheme before it. Has this ip address this public key and this these ports and um yeah? That's really about it and um maybe a bit about the signature and the sequence number. So the the in addition to the metadata, the node records, are always self-signed.

B

So basically, there's always a signature in the node record, it is mandatory and it covers the complete content of the node record and node records are always signed by the issuer, so they are assigned by the note that they are describing, and this is very useful because the node record information it cannot be um changed by anyone who is relaying, just node records.

B

So if you give your note record to someone else, they cannot change the information, that's contained in the note record because it's signed, but it they also contain the sequence number and the sequence number is mostly uh important because they solve and the update problem in a system where these records are propagated. And I've made a little overview here.

B

That kind of shows that so let's say we have a node record of the node a and it has the sequence number three and it gives this node record to the node b here and um then uh there's an additional node record, uh which is the which is the next version of the node record. So a updates its node record and updates it to the version four and it gives that version to the node c and then somehow node d receives both copies of these of this node record.

B

So it receives the one with the sequence number three and the one with the sequence, sequence, number four and basically um the sequence number. It allows the node d to decide which record is newer and in this case it takes the one with the sequence number four, because it's the higher number. So that's like the purpose of this is that if, if the node record is relayed through multiple other re-layers and it's also updated, then it's possible to decide uh which version of the note record is the is the newest one.

B

So that's what the purpose of this is- and this is even more important in a situation like this, where you have. um Let's say you have left side here and you have uh something like the uh dns discovery on the right side. So these are two different systems containing uh ethereum node records and the node d here is basically pulling information from both of these systems and if it discovers the node a in one system but also discovers it in the other system, it can still decide which one is the better one.

B

So in this case the version from the dht is the better one, but it you know, might as well just be the other way around that. Basically, maybe the dht doesn't really have the newest version or something of that particular record, and then in that case it could pick the other one but um yeah.

B

This is like the purpose of the sequence number, and I hope it's clear now and um one final thing before we're basically done um so there is this other thing in here, which is the identity scheme, and this is another very interesting property of the node records.

B

So basically in the node records it's possible to um to say inside of the record which identity scheme is is used and the identity scheme, it determines um how the signature is made and the signature you can see it here is in most cases right now, because there's only one identity scheme which is defined and it's the v4 scheme, it's a signature created by by the uh segp 256 k1 key and the current identity scheme is named v4 because it is backwards compatible with the discovery version, 4 identities and but other identity schemes may be defined in the future.

B

So it's uh and an open area of research to figure out. You know like what other identity schemes make sense and, most importantly, the identity scheme is also the one that is in charge of you know saying what is the node id, so um you can see it display here.

B

So the node id in this case is derived as the hash of the public key, but it can be different with another identity scheme, and this is just uh something more to uh yeah figure out yeah and it's one of one of the important things about these identity schemes is that they are like a very sort of long-term thing, so we mostly have them as a protection against um you know. Things like hash functions, uh getting broken, and things like that.

B

So uh I think that identity, if there is another identity scheme- or you know, if there's ever a new identity scheme, we will still be supporting the current v4 identity scheme for a long time, and um we will also not usually, you know, define new identity schemes, but it's more like. If, if there is, you know an an urgent cryptographic, you know emergency that requires defining a new identity scheme, it's possible, but it's definitely not something. We're gonna do all the time cool, so that was it with the presentation. I hope it answered.

B

You know some questions, I don't know, but I guess there's actually gonna be some questions. I hope.

C

um Yeah sure, actually that was a really good presentation. I think it really did set the stage very well. um I just want to give david the chance to if, if there's anything that you want to open up the the q, a with.

D

um The only thing can you can you go back to your slides for one second, I I just wanted to see. um I missed where this um give me one second here I missed where the sequence number was. Is that just encoded right into the note.

D

D

Okay, thanks yeah. That was the only thing question. I really had all right.

C

um So then, maybe I'll I'll start off uh with. So what exactly is included in the eip? It sounds like the discovery protocol is already there.

C

uh It sounds also like this is something a bit more protocol related than saying that it's actually the discovery v5, so is it the the data format that you want to be using right and what? What exactly is a part of the eip and what isn't a part of the eip.

B

Oh also, I just noticed I was muted, so I was talking to myself earlier. um No, um so I I have the eip up on the screen right now, which might be very helpful for this discussion right. So um this eip is very old and it only defines this format and there is nothing about the protocol or anything like that in this. It is really only about this format.

B

Does that change with discovery v5 so in the discovery v5, which is not in an eep? We are using this format, so the discovery version 5 uses this format in in the in the protocol specification. I can actually show you that, so, if you go to the discovery version, 5 specification, which is here and you can see it and you can search for enr- I guess it's yeah at some point: it's gonna be in there.

B

Where is it? Well yeah? I mean it's here so like basically, we are inside of the discovery version 5 protocol. We are using these enr objects and then the idea is that, like these objects are encoded as specified in here, so that's.

A

B

The thing yeah, I hope it does it clear up your question or.

C

Yes, that does absolutely answer the question, as in the data format, that's used in v5 is what is the eip here? It's saying that.

B

Yeah, but it's it's not just in v5, and this is quite important. So the thing is that if you check, for example, um we are also using the same format in this ep. So it requires the 778, because it is the same format. This one was created in 2018 and we are currently using it.

B

It's still in draft for some reason, but in practice this is deployed and used, and um it's the same for the 868, which is an extension to the discovery version 4 to allow uh relaying of ethereum node records, and this eep is also implemented by most giants at this time, and um it is another way of using the enrs, but it has nothing to do with the discovery version five, because this is an extension for the discovery version four, and we are also using the enr in here.

D

B

uh The sequence number in here so yeah.

D

So so 868 is basically an eep to say this is a way to find and use the new enr format, nodes right.

B

Yeah so, and we added the 868 um because um we wanted to have a way to to actually find all of the eons, so it's kind of um yeah most of this came about because of the because of the dns. So the dns discovery, which um again we are using already, is like the system where um basically the way we are generating. This is that you know there is a dns name and behind this dns name in text, records are contained in ours and um we didn't just want to put like a static list.

B

So the way we are uh generating this list, which gets put into this dns name, is by crawling the discovery version for dht and then um checking like if the node actually cont like, has an enr using the eight six eight in our request.

B

So basically we're crawling the dht and then we're sending the enr request to all of the nodes, and if they come back with an enr response, then we include the enr in the dns discovery tree. So that's kind of how this how this works, but um this is kind of they are not really used for anything else, though, like the enr request is not really used, I mean you can use it on the command line.

B

If you really want to, there is a command in the go ethereum p2p toolkit for checking like if the nodes support, like you know, you can ask for the enr, but it's not really gonna give you like anything useful. You know, okay,.

C

Do you foresee the need to extend the enr format coming up like you know, anywhere on the horizon, or do you think that this is it for in terms of the like? You know what nr object is going to look like.

B

Well, so the enr object itself. I mean it's.

B

Like I should have noted that, probably so um in the enr specification, it has these key value pairs right and these are sort of like the built-in key value pairs. So these are the ones that you can put and they're defined as part of the main in our format specification. So it says you know like how to encode an ip address and how to encode an ipv6 address and things like that.

B

But um actually um it's not like the only key value pairs you can put, and you can see that in the dev p2p repo we actually have a directory for enr entries and, for example, here is the specification of the e in our entry and it kind of says you know like what's contained in the entry so and uh there is nothing really. It was also proposed in an ep by the way, which is 2124, which is also last call right now, and this one actually um does um so.

B

Basically, this this entry is specific to the ethereum one blockchain and um in eth2 they are also using it in our entries, but um for some reason I didn't really put them into this directory. Yet I should probably do that, but basically they have them in the main e2 specifications somewhere. There's a section that says these are the enr entries and they have them.

C

Interesting so you're saying, even if there are new fields that need to be introduced, the enr format is extensible, so those could be added, and this is sort of like a lowest common denominator. An enr object must have these key values, but other key values could be added.

B

Yeah, actually there is, there are no mandatory key values except for id. Oh I'm looking at that right now. Now I see that yeah and so and then, but the thing about that yeah they are all optional, except for id, um which is uh weird I I do have some regrets regarding this format.

B

I can say after you know like after, like like three years of looking at it. It's interesting.

C

Well, I mean it over.

B

Again, what would you do well, like probably I'd probably like make the id not a key value pair, because it's mandatory and it's like it's a bit useless to put it in the body of the like. I mean if you, if you think about it, like the the structure of the node record, is basically you have the signature, sequence and key value pairs, and you can see the same here. It's like the content of the record is, like sequence, number key value pairs and then there's a signature in front.

B

So this is the the full structure, but when you actually have to validate the record, what you have to do is you have to uh basically extract this part here, like the con, the content part and then verify the signature over it. But in order to verify the signature, you also have to know what you're supposed to be verifying it against. So you need to actually check the key value pairs.

B

So the way it works in in in the implementations is that they do one pass over these keys and values, and then they first they have to find the id key and then basically, once they found the id key. They can kind of check like what type of signature is it supposed to be, and if it's supposed to be the v4 one, then they also have to go to this entry, which then has to exist, because it's a v4 record.

B

So it needs to have a public key and then they can verify the signature against this public key and it kind of feels like because you always have to do this lookup for the id key first it feels like it should just be. You know, like it shouldn't shouldn't, be a key value here and then the other big regret I have is obviously maybe not using ssc, um and this actually came up multiple times uh in the e2 discussions like why it's using uh and it's mostly because this format is so old.

B

I mean ssc, didn't exist when we made you know but yeah. Nowadays, I feel, like you, know it's kind of yeah. Well, you need. You need an rlp decoder to look up at the record and I don't know if, if that's like, I don't know, I mean it doesn't bother me personally, but I know that it's like some people, thought it's a bit of a bummer that you actually have to use rop to decode this, but like yeah, I don't know, can't have everything.

C

And I did there wouldn't be they weren't able to do something like put ssd in for eth2 because of compatibility.

B

No, they actually actually the e2s. The e2 enr entry is encoded using ssc.

B

A

Having it in each one as well or not, what.

B

A

uh We will be having this discussion soon in each one as well, for having us.

B

There will be some ssc stuff coming up yeah, that's this truth, but what I mostly regret is just making the format like I should have like independent of the encoding, because now I had to justify the rlp decision many times in the past, and it feels super weird because at the time when we made this specification, there was basically it was like the canonical format for everything in ethereum, and I didn't really think about it too hard.

B

I just kind of thought you know, let's use rop because we use it everywhere for everything sounds like you know, perfect choice and it kind of turned out that, like you know, people later were like you know, didn't like it or something I don't know, but um in practice you know it's totally possible to mix these things uh actually. Now that I'm very curious- and we should probably just kind of check.

B

If um no wait, what's it it's these 2.0 specs, I guess yeah.

B

Yeah there we go so here you have it it's the um you have the enrs and um in the ether um they have the ethnex key, which contains an scc bit vector, and they also have the easter key, which contains the fork id and the fork id is like this ssd structure. I don't know it's pretty much like the key, just as a c. Instead of rp.

C

Interesting um on a more general note, how much do these enr records in general add to latency in terms of ethers? um I don't know how relevant they would be. I guess they would be relevant to syncing, but also in terms of uh transaction propagation.

C

Like is there a concern that if there becomes too many fields that it's going to increase client latency to a significant degree,.

B

Well, I mean so one important thing about them is that they are size limited, which I kind of mentioned in the beginning, and it's also, I hope it's mentioned a lot like. It really has the 300 bytes limit and um it's not directly related to the latency, because um these are used during the discovery right. So when the peers are discovered, which is like a concurrent sort of process like basically.

B

Discovering the peers is not like directly related to what happens when the peers are actually being used and.

C

B

Yeah yeah yeah, but that's it so um yeah I mean.

B

Yeah, it's not really like.

C

Go ahead. Sorry, I didn't mean to cut you off.

B

No, it's no problem, um so the 300 bytes limit it exists because um they there has to be a limit.

B

um It's just a fact, but also if you check, for example, if we check the uh it's most important, for example, if you check the discovery version for specification right, so in there it's like, um I guess they have it wait. Where is it oh yeah, it's here so um so in the discovery version for wire protocol, the maximum size of any packet is 1280 bytes, and this is because of networking reasons.

B

I don't really want to go into it too much, but basically it's very good that it has this limit right and in the discovery version 5. It's the same, so the the maximum packet size is 1280 bytes right.

B

So, um since that's the case, it's like you know, and we don't really want to go ahead and relay these things across multiple packets or something so basically, it's like um it kind of makes sense to be limited in some way, simply because in the discovery protocol the message size is limited to the 1280, bytes and um and then in in the discovery version 4 in the enr response, you can have a single enr, so this is going to be up to 300 bytes. So it's it doesn't really touch this limit too much.

B

But then, when you go to the discovery version 5 um again and you can see that there's the nodes response and then the nodes response actually have multiple in ours.

B

uh And here it's like the size limit on enrs is directly determines how many nodes you can transfer in a single packet at one time right, because the limit for the packet is 1280 bytes. So you can put at most uh yeah four four units yeah, but there's also some protocol metadata around it, so maybe safer to just put three right and obviously, if the you knows are smaller, you can pack more.

B

But you know like it: there is like some like sanity limit, which is that you know probably you're going to be able to put like three or four in the in the in the packet and if we would allow like arbitrary size enrs, then this wouldn't be possible, like you'd, basically have like one per packet or something, and then that would really hurt the latency because you would have to actually like I don't know and then also in the in the dns it's different again, because in dns the message size limit at least for udp dns- is actually 512 bytes.

B

So there it totally makes sense that um the enrols are limited to 300 bytes, because um the 300 bytes limit applies on the binary encoding and then they may they may. It will inflate a little bit when they are encoded as the base 64..

B

So that will make them a bit larger and in the dns discovery they are input in the text record in the base64 format. So we are basically very close to the dns message size limit already with this very interesting yeah.

B

It's kind of a trend.

A

B

No, no, no, nothing.

A

So I mean I was just curious about this f2 thing like I had a question in my mind. Out of curiosity, this uh proposal. Is it helpful in identifying uh the um you know, details of a node operator, even in the case of f2, where up explorer can give back information to a node operator that your node is down or something.

B

um Yeah I mean it could be used for that it could totally be used for that. That's actually kind of an interesting, interesting thing yeah. um So in general, it's up to uh to anyone to put you know like to the to the north implementations they can put whatever they want in there. It's mostly about like finding a standard.

B

So that's like the thing and then also we are always trying with the ethereum p2p, to make it not so identifiable like the information early on, for example, we kind of try to avoid putting the like vanity information uh in the in the general ethereum p2p protocol. There is vanity information and you can find it. For example, you can set your own node name, but also the node name is automatically generated to show. For example, if you go to the east stats, you can see them right. I mean these. These are these node names.

B

um They are in this column in the node type column. So this information right here this is the vanity information, and this is relayed in the peer-to-peer protocol and in the enr. We don't really want to put this information because, first of all, it's very large information like it. It really eats into the 300 bytes, but also um yeah, it's kind of like um yeah. Well, it might just get a little bit too easy to know. Like you know.

B

What kind of note is it like? I mean it's more like the idea, but the enr is more like for, for for the for the kind of information that um that is really relevant to you know the operation of the blockchain like uh what like, for example, in the in the in the eth one enr. We have the information about like the genesis block and the forks that were applied in this implementation, and things like that and this this is really the most important and then like the vanity stuff.

B

Is it can be nice, but it's also kind of optional.

A

Yeah great awesome.

C

Yeah, uh so maybe just a last couple of questions from me that I think are related to this, so it could be that I'm just uh off on a limb here, but I've been in some conversations about eth1 node incentivization, as in on the eth1 proof of work chain, incentivizing people who are running full nodes, even though they aren't mining- and I know one of the concerns that I've heard come up- is that someone could just run one node and then just sort of relay it through a number of different ip addresses.

C

um You mentioned that in enr, once it's created by it by by the client, it can't be changed once it gets moved once it gets propagated into the network. Does that mean that enr might be a vector to see like you know, unique, unique nodes on the network? Would it be able to prevent an ip spoof like that.

B

uh I don't think so because it doesn't like it does not solve um the the simple problem in the very general case. So this is something that is like. The simple problem is real problem in all peer-to-peer networks and it's not something that can be fixed uh so easily.

B

um It's yeah generally considered unfixable, even um but um yeah. No, the the signature won't prevent this, like you can always create another record with another signature with a different ip, and it doesn't really help you with that. um I think the um the enrs can be quite important for uh for the incentivization, so in the in the light client uh protocol, there is uh some facility for the incentivization and they are uh developing it even more right now and um for this it can, for example, be.

B

I mentioned this couple years ago when, when we, when I first talked about the nr, that basically the the discovery of nodes, it doesn't always have to be. You know just about the ip it's more also like.

B

If you have some facility for it for discovering the nodes and seeing more metadata, you can also be a bit more picky about which node you actually want to use and, for example, if if the nodes were to use incentivization and basically what this would mean is you would have to pay them to download some blockchain info, then they could, for example, announce their general pricing range or something in the enr, and this would be very useful because when you would discover the node even without talking to it, you would already kind of know that you know this.

B

Node is offering service at a very high price or a very low price, and this is something that could be used for incentivization related things very interesting.

A

Great, so going a little more tangent on this, I'm curious to know your experience as an author for this proposal, as you mentioned in the beginning that it took a while to move from the uh one status to another, is it I mean like how would you describe that.

B

You mean, oh, my my eip experience. um Yeah, I can say the eip process is um great, but for the evm I think it works pretty well, because it is very easy with the evm to say exactly like you know, when is the change gonna activate and uh once that's decided, then all of the implementations have to get it ready and then there's hard fork and tests and so on, and then with the um with the peer-to-peer networking, it's always kind of the problem that I think there are two problems.

B

So one problem is: it is not tied to the hot fork, so there is no need to uh yeah. There's, basically, no need to uh to define the hard fork. uh Sorry, I stopped the screenshot so the uh when, when when the hard fork happens, um it doesn't really influence and most of the time we just ship the updates so that they would kind of be like available after the hard fork in the in the in the networking. But there's no requirement for that until yeah.

D

B

Cannot really do that and then the other problem is that historically like right now we're in this unfortunate situation where go ethereum is very popular and everyone else is not so popular, and this is something that um we in goethe and we really hope it will change, because it puts a lot of.

B

Yeah a lot of responsibility in our hands to get everything right, um but also uh in go ethereum. We have been very, very um yeah like let's say uh we have cared about backwards, compatibility a lot, and what this has resulted in is that other client implementations haven't really seen the need to uh implement uh these features in time.

B

So, basically, right now we are still supporting uh from the networking point of view. We can still talk with parenting notes from 2014 or something like you know. No, they didn't exist back then, but you know like um we can still talk with very, very old notes even now, even though they are totally unc incompatible regarding the evm uh for these days.

B

So it's like, uh if you would run the go, ethereum version 0.9 point something it would probably still connect somehow to some other note, and it's like it's not the the best uh way, because it means that, for example, in parity specifically, some some of the eeps are not implemented. The networking eeps- and this is mostly because they didn't see the need until now to really implement them, and we never really turned off the support for the older version and it's.

B

It means that, like it was a very slow process and we would really like to have more uh like to be more strict about this and really define some deadlines where you know it's like you absolutely have to implement this feature by this time, maybe tie it to a hard fork after all, and in that case I think the eip experience would also get much better, because then it would be very clear to the editors that okay, this is for this fork, and this is for this fork and this client has it.

B

This client doesn't have it it's something that right now. Basically there isn't there isn't even like a list that says this client implements this networking or something it's more like you know they just kind of like.

B

I just occasionally run some tests on the implementations to see if they have certain features, and sometimes they do and yeah I mean right now. The visual, for example, is very good. They they have a lot of the stuff and I uh open ethereum. It doesn't have a lot of the features. So that's approximately, where I can say never mind also like halfway. I don't know they have some, but not others, and it's like yeah.

B

It would be nice in the future to have a more strict process for for the networking changes, but then I'm also a bit fed up with this erp proposal process because it's very hard to get feedback and I waited for feedback on my eeps for a long time and nobody really said anything so in the end we just decided to ship anyway, after waiting like a year or something for people to like I mean I, I yeah, I don't have the screen share, but I could show you like. I made the you know like here.

B

You can comment and I put some like notices in the relevant chat channel and say: hey guys, you know, like here's the note records, will you check it out? It's very news. Useful and people didn't really respond and um yeah. At some point. We just decided, you know what, if nobody's, gonna respond, we're just gonna go ahead, and this is not the best kind of situation, and I think I would appreciate it. I I never really knew like where to put my proposals, and I think this is something maybe different.

B

Now with the cat orders and the forums or whatever. Maybe there is a way like magicians. Maybe there is actually a way to discuss these things now, which didn't exist before I don't know, but for this, like magicians did not exist either or maybe did, but I didn't know about it or whatever.

A

Thank you. Thank you. So much for your feedback. I mean like one of the purposes of having these calls with authors and sharing about the processes. Is you know to making people aware of what changes are getting into the system like?

A

There are certain changes that have been imposed and we are trying to implement it um for the eip standardization process and we are trying to look into every proposal which are stuck for a while, maybe a year or two or more than that in the draft status or the last call status or have not reached to the final statuses.

A

So we are trying to push them forward with the help of author itself to move along the process and get to the final status as well as to let other people know that there is some standard available that you can start making use of. So for this particular proposal.

A

um I see that the last call period has already passed long ago, so we are proposing you to go ahead and create a pull request to change the status to final, and with the help of present eip editors, we will try to move it forward along the process.

B

Yeah, well, that's it that's great.

A

Yeah, and not only for this, uh this particular proposal, but for all the proposals which are there in a networking uh uh list eips.ethereum.org we are looking into uh one by one, each of them and then we'll try to get it through the right place.

A

We are close to hitting the time. Does anyone has any final question comment? uh Maybe uh david? If you have anything from basu's side to share.

D

No, I think that covered everything I was looking to get out of this. I appreciate you guys taking the time.

A

Thank you for joining us today, so I hope that today's episode will help uh climb client implementers, who haven't limited it completely and others who who are trying to understand the proposal to you know, and this proposal will soon move to the final status in the eip standardization process.

A

uh I believe the ethereum improvement proposals are great work by contributors of ethereum ecosystem, but maybe a little less visible. So, with the help of this peep and eep series, we are trying to share more information to the community at large, sharing, more and more questions comments for the proposals that we can include in future. Episodes of people thanks felix the beso team and our awesome cathedrals for joining us today on the peep and eat, talk for people who are watching us on youtube.

A

You may find I get a handle of the today's guest and the rest of the participants in the description section below if you have questions comments or concerns about this or any other proposal, or if you have any suggestion on which proposal to be included next in our show, please leave a comment and you can always reach us on twitter if you like, this eip focus series share it with other community members and let them know about penny, do hit like share and subscribe to.

A

The channel channel see you next week with sam wilson and and scott d tricks to discuss eip2938 obstruction. Part two like on uh on community demand. We are having a second part for this particular proposal. People had some questions that we could not answer in the first episode that we made for proposal 2938.

A

So we are hoping to talk more on that proposal till then keep sharing your love with us. This is your host pooja ranjan signing off. Thank you. Everyone thank.

D