The ERCs tierlist

Transcript

Hello everyone. My name is Adrian and uh today I'm going to take you on a journey through the ERC world. Uh there are many ERC's. This is from last week. I'm sure more have been merged since then. So last week we could count 520 ERC actually 519. There is one EIP in the middle that we'll discuss later. And you see that there are there is a dependency between different TRC's. So it's like a growing word and living word. Some are finalized, some are still draft and everything in between. And some have even been withdrawn because authors realize that they were no longer relevant or some are just stagnant because authors don't don't abandon them basically. Uh and so I wanted to explore the the life cycle of the ERC not just

in terms of of what is described in EIP1 in terms of like oh you have to be a draft and review and so on but more in terms of how useful they are and and what their their evolution uh in for your ERC needs like most of them or most of the important ones I'd say are implemented in open zeppelin. We are currently having a release candidate. So if you want to to implement on both of one ERC you could check here or if you're an ERC author maybe you also want to contribute to having your standard be provided have a standard implementation in open zeppelin contract. So this is a tier list I'm going to try to do today.

Those are my different section from the bottom all the way up we have that's not even an ERC. So I mean that's the lowest effort someone could make in my opinion is not even going through EIP1 and trying to standardize something and and not doing it properly. So if you're trying to build something standard and reusable, please at least make it an ERC. At least it would put you in the useless category which is way higher. Uh above the not even an ERC we have in retrospect it was a bad idea. Uh you never start here. You just try to do something useful and a few years or months later we realize it was a bad idea. It's okay. Sometimes you harm the ecosystem by doing so, but ideally like this would be avoided if more people that are currently not involved in the

process were involved and were providing reviews. So if you want to avoid someone doing a bad ERC, you should jump in and provide reviews before it's too late. There is not even the authors understand it. I'm not saying the authors are stupid. I'm just saying they're trying to do something very smart, sometimes too smart, sometimes nobody understand it. Sometimes there are corner cases. And if there are corner cases that are not fully specified, different implementation will handle them differently and then we have bugs and we have stuff that is non-standard which is what we wanted to avoid in the first place. Then there are the useless ERCs.

They are not bad. They are not good. They are not harming anybody. They're just here and most of them are useless. Uh then you have the actually useful ERCs and we are getting into the goods. actually useful ERC's are the one that people deploy and people use and that improves ecosystem for everyone. So if you write an ERC and it ends up being useful, good job and thank you for your work. And above that you have the ecosystem shaping. So here like you are in the ERC that are so great that basically they define how the ecosystem will work. They define how the interaction will work and they're shaping the next generation of contracts. So again, great work if you manage here. And I reserved a got tier section just in case because some might be like really nice and we'll see if any

ERC make it to to this tier. So all views are my own. They do not reflect any of official Open Zeppelin point of view. If you're mentioned and you are unhappy, we can discuss afterward. Please don't be mad and please have some sense of humor. I'm going to say nasty thing about ERC's including one I personally wrote. So, let's start on the first one. This is one I really like. Uh, personally, it's a payable token. Uh, it's been just authored by one person. It it's an evolution of your C20 that allows callbacks and that in my opinion can be quite useful. It's not that widely used, but it's has some usage. I'd put it in actually useful even though like there is a very specific corner case that is underspecified. To me, it's useful and it's an evolution of CRC20. So, we have

to discuss CRC20. Uh, a lot of people hate RC20. A lot of people love it. Uh it has bad design features. If we were to do it today, we would do it very differently. Nevertheless, we wouldn't be here today if it wasn't for ER20. It enabled DeFi. It enabled unis swap a and so on. It definitely shaped our ecosystem. And in that regard, it's an ERC that that that made things better. I think in in this ecosystem, uh 1363 also mentioned ERC 165. Um, ERC 165 is when you looked at the graph before earlier, it was the one ERC that was the most required, the most mentioned. So, basically most ERC require some form of 165 compliance. Uh, but the thing is that even though like most of people

that deploy contract deployed 165, I don't know anybody that actually uses it and that actually looks at the interface for checking stuff. So, it's useful. So, so it's it's useless. Yeah, it's it's completely and utterly useless, but it doesn't harm anyone. uh you have other token standards that try to improve on your C20 like you have your C777 that tried to be smarter with hooks and you had to register in 1820 and if you have time I will explain to you how I lost bitcoin because of that it was test net bitcoin but in retrospect it was a bad idea that's probably one of the only contract that open decided to remove from its library for security reasons uh another token that you may know about is 721 uh I think it's really nice uh again like

maybe people will say like it could improved on, but it has fewer flows than your C20 and it created uh a large section of our ecosystem. Maybe one section that we sometimes don't like. Maybe we don't like all the NFT drops that happen, but it's still ecosystem shaping for us, better or worse. Uh another token that is quite used and quite well known. That's basically bridging the gap between ERC20 and 721 is 1155. It's quite nice, but doesn't have that much unit. Wallets don't support it well. So, I'll put it in the useful category for now. Maybe in the future it can becomes ecosystem shaping but I don't think it's there yet.

You have two to three. I don't know if you know this one. This one I particularly hate. Uh it doesn't require ERC20 but it implements the exact same interface. So the function selector do clash but they have different behaviors and it doesn't include 165. So you don't know how to you don't have any way to make a difference between a 223 and a 20 and they would behave differently. Hopefully like there are not that many 223 tokens anymore but this is like in retrospective was a bad idea. Uh we also have 677 you will see that the screenshots a bit different here and the reason why it's a bit different is because it's not present on the ERC website because it's not an ERC. Uh people just wrote the document put it in a PR on the on the on the on the ERC

back then it was EIP repo. It was never merged. So it's not an ERC. Sorry. So like we ate some people hate ERC20 but overall like it's better than most of the things that came after it and tried to improve on it. That's also why I put it that high. But there are good extensions to ERC20. We have the ERC20 permit extension which you may have used that was quite useful. Now we have uh smart account with 227. So we don't really need permits anymore but they're here to stay and they're actually quite useful. Uh we also have the 712 type of so this is an EIP which I think should be an ERC back then ERC and BIP were a bit fluid we did not the naming

convention was not clear but this is definitely not an EIP because it doesn't affect the node or the protocol it's just a convention between wallet and contract so it should definitely be an ERC so it's only EIP that I will put in this list and this EIP or ERC basically defines how we do signature in a way that is human readable it's way better than the 191 signature where you had like an abstract hash and people have tried to improve on that and nobody ever succeeded improving on that and and so far it's what we all sign and it applies to everything it applies to token to defy to governance with votings to smart accounts like the 4337 um entry point uses that for preparing the the hashes

of the user operation to me it's like it's an IP that is used everywhere or any that is used everywhere in the space that improves security for everyone and that we've never been able to replace with something better. So this is going to be our go first go tier ERC and and probably the only one today. Uh there is also uh 1271. So 1271 is um we're in the signature scheme world here. We we just saw permit 1271 is a way you integrate smart accounts into the world of signature verification. uh otherwise like you just do an easy recover but if you have a smart account with a multi or some sort like it doesn't work that way so this is really something that is extremely useful uh and that in my

opinion is ecosystem shaping people are trying to I mean we are trying to build on top of that and extend it but it's not replacing it it's it's extending it what what it does today does well and we don't want to break that and then there is 4237 so this is an ERC that that you may know of it's it probably is the first one that is nonfal that we are seeing in this list. Um if you don't know about it, you should definitely learn about it because I think it's it's really important. Uh it's nonfal. It's still moving. We went from version 07 to 08 of the entry point recently. So it's still not finalized. I think it will still go up. But right now it's already ecosystem shaping in the sense that it basically defined in my opinion how you do decentralized user operation really

for smart accounts. And once it's final and when it's more adopted with better support through 7702 and so on, it's possibly our next candidate for gut tier. Uh but with 437 comes 7562 that you may or may not know about and this one is horrible in the sense that 437 requires some uh storage restriction on the account verification side. uh which makes sense like you understand why DCRC exists but if you've ever read it uh maybe you you needed to a good glass of water and some medicines after because it's it's really really hard to read. I'm sure like whenever you read it you're missing part of the stuff because it's so complex and I put it in not even

the author understand I'm not sure any single person on earth is able to give all the specification that is in the CRC without having to look at the document. uh there is also like talking about smart account we mentioned 437 and 1271 there there there are a few that are trying to do modular smart account and some of them I like some of them I don't really like uh there is 6900 I don't remember who but there there is a project that that uses that possibly in production uh it's horrible uh I mean I'm sorry if you are not aware of it but uh it's so complex there are so many moving pieces it's so easy to mess things up there are so many corner cases that are not properly documented like try to do something that is really

really useful but they do it in a way that is basically unreadable and I'm worried that many implementation will not be consistent with one another because of this complexity which makes me put it in the not even the author understand it now maybe in two years we have the same talk and I revisit things and I say oh it's ecosystem shaping because all of a sudden everybody uses it and we have we all have modular smart accounts but so far I think it's more complex than useful Uh there is 2771 still in the room of smart accounts. We have like the metat transaction native stuff that we built during covid this yeah September 2020 we were in lockdown while we wrote this one uh metam mask myself run and many people like it it was nice uh it enables uh

generic metransactions through forwarder and that's why we have the context contract under open that so many people dislike. uh it used to be very useful. I don't think it's quite useful anymore. I mean it's it's useful in some context like 7579 uses it somehow. So maybe it will have usage in the future but if we do the same talk in two years I'm pretty sure it will drop down to useless by then because account abstraction just took over everything. Uh talking about useless ERC this is one we wrote at Open Zeppelin about standardizing custom errors in smart contracts. But the thing is like contracts are already deployed are not going to update to produce new customers. And I'm not sure anybody who verifies and reads custom errors anyway

beside during testing like when a customer is triggered in production on test on mainnet not surebody anybody cares about being able to decode it. So we try to do something I think it's probably one of the most useless thing we've ever done and standardizing customer in my opinion is really useless unless uh it's done by unis swap and it's like a way to wrap stuff and build proper traces in which case I think you could do something related to customer that is quite useful maybe not fully useful yet but probably useful at some point in the future so that's when unis swap takes takes over it's it's a bit better than when we do it alone uh I mean other stuff that I was involved in like it was old uh I was

working on oracles with my previous company uh we try to standardize some stuff uh it was withdrawn so this is going to be useless but at least the other recognize it and they are not polluting the stuff we the place we've we final RC that we don't need it was withdrawn which is the correct thing to do when you know you have a useless ERC okay then uh the diamond proxy So very you may know the diamond proxies pattern. Uh so this ERC doesn't standardize the construction of a diamond proxies. Diamond proxies existed before that with 1538 that has been withdrawn and you can build a diamond proxy without following that ERC. What this ERC standardize is not the idea of a proxy delegating to different

implementation depending on the function selector. What this ERC standardizes is the interface through which you are going to look up and to introspect the configuration of your contract or update it. And until a few weeks ago, I thought it was the most useless ERC because I thought nobody used it. Uh the naming made no sense. The function made no sense in the way they were written. It was overly complex in my opinion. Uh and it could be done way simpler. But then I realized that all of the sudden Etherscan decided to consider it, look at it and right now if you have a diamond proxy on mainet that exposes the correct uh facets and loops as specified

in 2535. Now you can explore the configuration of your diamond proxies through ether scan. So it's somehow useful. Maybe not fully useful but somehow useful. a good job on on on ether scan basically turning this useless into ERC into a somehow useful ERC which means that the whether a ERC is useful or not is not just a matter of who writes it it's also a matter of the ecosystem accepting it and using it and agreeing on on its value the author is not in full control of it uh there is 7201 that I wanted to mention again another ERC I've been involved with uh we did it because we we think it's good to have namespace storage. It's useful in the context of

diamond proxies for example. We think it's in useful in general in the context of upgradability. And this was in particular, this one in particular was also written with vertical trees in mind. Even though like vertical trees might be duplicated in favor for binary trees, I think we'll still get the same extension mechanism. So it still somehow makes sense and I was not expecting that many people to adopt it, but it feels like a lot of people are using the formula we standardized here. So maybe it's one of my first useful ERC. I'm happy with that. Uh, okay. So, those are all the ERC's I wanted to rank today. As you saw, there are many, many, many others. I'm sorry I cannot rank all your favorite ERC's, but what I want to ask you today is, yeah, this process is only as good as the

people that are involved in it. And the more people are involved, the better for everyone. So, if you are building something that could be standard, write an ERC. And don't stop at just creating the pull request. Try to have it merge, please. Um if you are not building anything standard but you worry about standardization uh review yours review other people yours give feedback try to improve them uh we have the is magician forum for that uh all the life cycle of yours is documented in the IP1 uh every one of us should worry about that should take some responsibility in in being part of that process so that's what I want to encourage you to do today and these are the obvious like links if you want to know more about how we deal with

ERC's and how we implement them. So now we have a few minutes for question. We can discuss anything ERC related and I could rank any ERC you want me to rank as long as I know it. Uh thank you. Uh is it half of space invaders? That was not the idea. No, but maybe it is. not on purpose. Uh hello, could you talk about uh RIPs and uh uh other uh uh IPs uh that are maybe being developed, but

RIPs? Uh well, I mean, yeah, the the space is split between EIP uh or ERC's, RIPs for for crosschain things. There there is also capes uh crosschain agnostic crosschain improvement proposals. Uh so there are different spaces. The the EIP process is very specific because it's for for Ethereum nodes and and and protocols. As far as uh ERC's versus RIPs versus caves, I mean RIPs are kind of strange because they mix both EIPs and ERC's because um I don't remember the name, but the one for the P256 pre-ompile is an RIP. So like it lives

on the EIP side of this space, not on the ERC side. So yeah, sometimes if your standard involves more chains besides just Ethereum, if it's L2 related or if it's general interoperability related, it may be a good place to put it in RIP or capes. Um, but yeah, otherwise it I think it's both mostly the same process and I think they mostly follow EIP ones. It's yeah, it's kind of random that there are no RIPs here, but they could very well have been we could take an RP and sort it with it with this. It would make sense.

Nobody has a nice ERC they like that they want to rank. Uh hello, thank you for the presentation. Uh do you have an opinion about the EIP 4626, the interestbearing token standard? Yeah. Uh yeah. Uh it was one that I removed because I thought I would did not have enough time to discuss everything. Um so honestly I I like the approach. I like where they are going. I think it has the potential to be useful. There are a few things that I don't like with it. One of them is that there is no slippage protection included in 4626. So if you wanted to do slipage protection, you either need to have a router which means more token movement and more gas spent or you want to expand for 626 with slipage function which I

tried to propose. I think it was 5143 nobody cared about that. Uh there are also like efforts to make it asynchronous like 7540 which uh so yeah it's it's it's a bit of a complex world. I like the concept of 4626. I'm not sure how useful it is today. Like if I had to rank it, it would be somewhere between actually useful and in the middle between useless and and and useful. It's at least useless and probably somehow useful. It's just that I don't maybe it exists, but I don't know any like UI that allows you to explore many uh liquidity system and that leverage 4626 to unify all of that. If that kind of things existed then it would bump up the utility of

4626 by a lot possibly at some point making it ecosystem shaping. Thank you very much. [Applause]