Getting your EIP included is harder than getting a Ph.D.

Transcript

Hello everyone. Thank you for coming here today. Uh I'll be discussing what I'm always discussing at ATC which is basically the community around ERC IP and standardization. But today I'm going to have a look at from a different point of view. Last year we looked at this. This is Ros of all the ERC's that that exist or at least that was ERC's from last year with their different status uh whether they're final draft and so on. Uh and yeah it's something we are really interested in because like we at open write smart contracts for everybody to use. We are to some extent the reference implementation of many things. So we really want to to have a look at what

ERC's are out there and and we try to contribute to this space by also writing our owns. uh and if we look at the evolution over the year like there is no significant thing to discuss like everything is is going on uh lot of draftier fees few less stagnant so maybe people have revived ERC's and yeah overall it's the same thing but this is just part of the ecosystem like the system is much bigger this is all the EIP so ERC's are a subset of the ERC's and you can see the it's no longer colored by status it's colored by type So everything you saw before for ERC's is no light blue and you can see other stuff and you have a big cluster of ERC's but you also see a significant

cluster that is green which are the core ips and the core ips are the one that define the behavior of the EVM and it's the one that we at open are particularly interested in because they define the virtual machine that will run our contract and so we want to know how would this work in order to build good contract and sometimes we even have ideas on what we could put in this space to help us build better contracts and it's very hard to push stuff because we're not core devs and core devs are basically the one deciding. So we decided let's let's become core devs. So I'm very very proud to announce today that Open Zeppelin wants to be part of this core endeavor and in order to do so we just launched our new execution client and obviously being open Zeppelin

we will optimize our clients to be more effective at at running open Zeppelin contracts and because we are smart contract developer we are writting it in Ule which is quite interesting for us because it means that our clients needs to run inside another client. Uh yeah, no we are not going to do that. I'm sorry. Uh no, we're not going to do that. But we're still interested in the IPs and we're still try to propose the IPs and core devs reject them and that's okay. That's part of the process and we're not going to to start fighting that. There is a big road map ahead for them. But question is who write those standards? If you look at the ERC's, there are roughly 580 ERC's authored by about a thousand a thousand unique

authors and you have roughly 2.6 authors per ERC's. And whenever you do this kind of statistic, you have this common distribution that happens everywhere. You would see the same distribution if you were ranking earthquake and things like that. You have this inverse square in inverse function that happening. And you see that a few authors have written a lot of ERC's and a lot of authors have written just one ERC but those are all the ERC's uh including the draft one and the withdrawal one. So if we look at the one that possibly have a bigger impact we're going to just look at the final ones and the final ones are just 134 today. I mean a few last week when I prepared the slide for 281 unique authors. only like about a quarter of

the of the of the authors have gone all the way to finalizing an ERC and and you can see that you have the same distribution if you look only at final se uh the number of author on average per ERC is a bit higher for the final one I think this just basically means that if you work in group it's less likely to be forgotten on the side and maybe you can share the effort and also if you share your idea with other people it's more likely to to succeed But we can look at the same thing for EIPs. I mean, and here it's core EIP.

I'm not looking into the networking and the meta and all the other just the one that define the EVM. And like you have in this case fewer unique authors than Corey IPs. Uh, and it's it's a way smaller community. There are I mean not almost as many. There were 580 ERC's, but it's it's comparable. And there are basically a quarter of the almost a thousand unique authors you had for ERC. So it's a way smaller community with people authoring a lot of them. Vitalik being being a particular case but like if you just look at the top 10 they all have more than 15 EIPs and those are all EIPs including the the draft one like Gal has a lot that are

vertical and stateless related. If you look at the final one, he goes out of this unfortunately, but you still have like a lot of of of um of of of I mean a smaller group of of photos for these final. So it's a way smaller communities than ERC's I would say. uh and the thing is that ERC's and EIPs are supposed to be governed by the same work, the same process in the con that it's EIP1 that defines how you write as such a standard document and how you get it to to evolve. So, so is it the same community like it's governed by the same rules or is there any overlap between the two and I think there should be some overlap and if we look this is all the

authors that have authors either Corey ips or ERC's and the blue is the fraction of their authorship that is corps and the red is ERC. So basically if you each each column vertically is an author they're sorted. So like if you only authored ERC's you are red. If you only authored EIPs you're blue and if you've authored both you are one of the 54 you are somewhere in the middle. So here first like we see what we saw yet previously is that an overwhelming part of the standardization effort and in terms of numbers of contributor is on the ERC part but also like the overlap is quite small. If we don't look in percentage of each everybody's

contribution but in row number it might be difficult for you to see in this I hope it on on the recording it's better the slides are available on my website you can see that what's interesting is around the middle we see that this part those are ERC authors that have authors more ERC's than the other ones so what I would guess here is their profile that are a bit like me is they've written many ERCs and at some point they want to try it into the EIP and sometimes met a lot of frustration. On the other end, there are a few EIP authors that have written ERC's very very early on like in the first two or three years of of Ethereum. Um, when there was also like the the community

was was I think more tightly coupled. Those are for all Corey IP and ERC's. So, you know the drill. We're only going to look at the final ones now. If you look at the finals one, fewer person on both sides overall the same the same dynamic. >> No, it's not the same. Uh oh, sorry. Oh, yeah. Sorry. I You're right. I clicked the wrong button and they look very much alike. Thank you very much. Those are the final one. It looks very much the same. Uh maybe the EIP site grew a bit in proportion and if you look at the intersection, it's only 10%. So in our entire space only 10 individual have written both final core ips and final

ERCs. I think this is like really showing like those are two very different communities. Um so so so why is that? Why is the process any different? Because they all have to go through the same thing like they have an idea and they have to go through different loops up until it's finalized. And this is is very different if if you have one to autoc you have your idea you write it down you follow the format you get it merged and that's basically it and there is no guarantee of quality that's why it's quite easy to build a a final ERC you're supposed to make sure that the community hears about it and can provide feedback and you're supposed to to make sure that you engage and you consider other similar ideas and that

you make your best effort to make something useful. But nobody's going to verify that. And there are final RC's that are really bad and there are sometimes multiple final RC's that are addressing the same issue in different ways. If you want to do an IP, good luck. It's basically the same process in the beginning except at some point you'll have to go to an old core dev meeting and convince core dev that it's a good idea that they put your uh EIP inside a hard fork and that's where you have to prove that it's not just a sound idea but it's secure it's valuable of their time and effort it's not going to uh affect the network security or or throughput or or whatever and you have

to get it scheduled and you're fighting with other EIP is on that very limited bandwidth uh that that they have. Uh and yeah, ideally you'd be aligned with the Ethereum road map. Uh and if you're included, that doesn't mean you're getting used. Um maybe like a few EIPs have led to pre-ompile that nobody cares about. But overall, like just being included is already a great metric for for success. And you have to fit somewhere in the middle of this. If you don't, well, good luck. People have tried. It's very frustrating and most ERC's authors they come to the EIP process with just an idea of yeah I want to involve the EVM so that contracts can be a bit better and so on but if it

doesn't align with this map uh yeah it's it's very very difficult to get attention and even things that you as an ERC author feels are very minimal change to the EVM the EIP edit the core dev will see that very differently because they see it as a potential risk for for the blockchain Uh so yeah conclusion is like as anc you can be tempted to write IPS uh understand that it's going to come with a lot of frustration if you do it as part of a team you have a lot more chances if you are aligned with the serial mode map is way better if you don't find anybody to work with you on that as a team probably not worth pursuing because like you need to convince the entire ecosystem. So if you

cannot convince two or three people to help you, it's going you're not going to a good direction. And in the end, it may feel that finalizing an ERC is way easier. And it is, but it's not a guarantee of quality. And in the end, there are very very few out of the 300 and something final ERC's that are actually useful and that have impacted the ecosystem. Uh so while you may think that it's easy to to go the ERC way, in the end having an ERC that has an high impact on the entire ecosystem might actually be as hard as as getting an IP included. But you won't know if you succeed or not until years after uh you've you've basically written it. And if you want to have an idea of what I

feel are good ERC's that have impacted the ecosystem positively, you can watch my talk from last year. Yeah, thank you. >> Thanks. Um, we have five minutes for question. Anyone have? Yes. >> Should there be some kind of quality check over ERC's? >> There should be.

>> And and what kind of >> we we we would need a process for that. we don't have a process. Uh reviewing ERC's is a very big effort from the ERC editor. They're already doing a lot of effort just reviewing that the document align with the the required format. deciding whether an ERC is valuable and and a good solution and meaningful to a generic solution to a generic problem uh is is is difficult and I'm not sure anybody in this space wants to be taking that responsibility. Uh you have companies that come to the space with

products and they want to say that they are doing standards. So they take their product specification, they put that in an EIC document. They say, "Oh, look, it's standard 8,000 something something uh we implement it, but it's the other way around. It's it's standardizing their their implementation." And they say there are standard behavior and this even if the thing is in draft and you see any issues, you want to come as a community member and say, "Hey, you could do it better." They are going to say, "Yeah, but it's our product. It's been live for two years, so we're not going to move it." And a lot of URC's are basically like that. I don't want to to blame anybody, but it's the thing.

So, uh I'm not sure anybody wants to start fighting these kind of behaviors or try to take ERC's because an ERC can be draft and can be very very useful. 437 is still a draft and people use it and it's part of a big thing. So not everybody wants like you would have to go to all the ERC comment and so on and give feedback and someone would have to go see the authors to make sure it goes in the right direction or you'd have to change the authors. It take a lot of time a lot of effort and the the benefit of doing all this hard work is not really clear. So I mean I think the solution is everybody in this room and out there should take part of their responsibility. If we share that

responsibility, if we all go to the is magician forum to leave comments and if we all push, maybe we can achieve something. But I'm I'm not optimistic. So I think part of the benefit is you there's 8,000 ERC's to look through and if you've got no measure of this is somebody's product written up in a different way or this is an actually widely used standard, then there's no market signal. It's it's a massive amount of work to be able to say these are the things I need to look at those things might be interesting.

>> Yeah. I mean there are not 8,000 the ways are number means there are way fewer than that but it's true that it's sometime difficult to navigate and and honestly like this is also where I think we as open zeppelin we are part of the solution in the sense that we spend time reviewing these things and looking at them and identifying the one we think are valuable to provide implementation so that people that have a product need can go to our thing and see like okay they do it that way using this ERC maybe I don't have to go through the many hundreds that exist to find the one that is meaningful. But also we don't implement all of them and if you think that what you want to do has not been implemented yet uh you'll have to go

through the list. uh and yeah and it's a very tedious process and I think what's even more tedious is when you want to write one you should make the effort and it's a very hard effort to try to understand what is the core problem you are trying to fix and take a few steps back from what you're actually building from like how we could generalize that and and that's a very difficult effort to do when you are building the thing when you are reviewing an ERC it's also very difficult to do that's also why like having external people review ERC maybe some of them will have the right angle point of view to to do that that discussion but ERC editors are not the right persons to do that I guess.

>> Okay, next question. >> Y >> thanks. >> Um thank you. So my question goes related to the use of AI. I have noticed that since we have LLMs people don't go too much to Ethereum magicians and comment. I think the discussion is basically dropping. So do you see any solution or way to encourage people to actually contribute in an nonautomated way? I mean I see how you could use AI to scroll through the list of ERC's and try to get feedback from that. But at some point when you want to comment and build a standard we have to do it as a

community. Like if you talk to your agent locally that's not how you're going to spread knowledge. Uh so um maybe AI I mean AI has been used uh to some extent in the in the EIP process to summarize EIPs before hard fork and to help people uh uh review the thing understand what's going into our hard fork and and engage better. So maybe my comment is uh uh we'll still need I think is magician form to discuss. Maybe we need an AI agent that scrolls through that creates summary and present them in a very easy to understand way on social media on whatever platform to to help people identify the signal from the noise and direct their their effort to the right location. But in the end the

decision should be human to human in my in my opinion. >> Okay. Another question. Yes, >> thank you for your talk. Uh maybe it's a dumb question, but if I wanted to create a standard, should I start with an EIP or an ERC? >> It truly depends on what your standard is about. If your standard is I want to standardize the way smart contracts are composed on chain, the way different contracts will communicate with one another or the way uh an external tool like a wallet will do signatures on chain. This is an ERC and you the

standard is helpful if you want to synchronize actors but those are things you can do on your own without a standard if you wanted to. You would do an EIP if you are trying to modify the behavior of the network. If you want to get included in a hard fork say from now on I need a pre-ompile that does this cryptography or from now on I want to add a n code that does count leading zeros which has been added recently that you have to say like I need to modify the consensus for everyone and that would have to go through an IP and if the community and core dev basically don't agree and don't modify the behavior of the VM there is nothing you can do about that as an individual.

Okay, thank you. >> So it's end. Uh thanks again for presentation.