Ethereum needs Standards Punk - Sebastian Bürgel - Gnosis & HOPR

Transcript

All right. Uh, welcome everyone. I'm going to talk also without slides. That's fine. I'm going to introduce myself. Um, I'm Sebastian. I'm Yeah. Uh, VP Technosis. I'm also founder of Hopper. I'm also Sebal. And I'm here today to represent what is maybe in this room the smallest group but overall I think an important group which is Ethereum app developers and probably most of you are familiar with uh some of the apps and services that Nosis is building. In addition to that I'm uh working on a mixet for anonymous communication called Hopper on top of which we're building the most

anonymous VPN. But this is not what it's about here today. I'm here today as a concerned citizen of Ethereum. And um I guess now's the time to use this clicker. Um I'm concerned not because of Solana. I'm not concerned about Bass. I'm concerned because many of my fellow app developers are not actually building on Ethereum. They're building on an increasing number of centralized RPC providers, centralized indexers, centralized bundlers, and increasingly centralized custody under fancy names. And I'm very very concerned about that. And my thesis is that this

is not because of stupidity, laziness or you know inability but because we even in this room are unaware of how broken Ethereum really is. Now before we get there uh just to gauge the level of of in this room is there anybody who has not been running an execution layer client or fiddle with you know curl to access you know an EL client anyone no shame okay well okay um yeah so basically a blockchain is for writing and writing gets a lot of attention right I'm just going to

speedrun this intro sorry for that so Ethereum Blockchains are for writing. That's kind of obvious. Gets a lot of attention. Fossil and all sorts of other things that we talk about a lot. We do not really talk about that blockchains are also for reading, right? Only that reading gets a bit more complicated than that. So there's two ways that we tell application developers. You can read from Ethereum. You can query storage, but we tell application developers to kind of s store responsibly and you can use logs, right? And to obtain logs, we use something that by the way, Felix, thank you for this uh wonderful motivational intro for my talk here. Uh uses ETH get logs. Now, you know, sorry

to bore the uh client devs in the room. Why do we even talk about this? Well, because things are not so easy. At Hopper, we have a decentralized network. We encourage everyone to run their own Ethereum client, right? We actually want to build on top of Ethereum and not on top of a bunch of centralized services. What happened this summer? Uh this summer many of these nodes had a catastrophic panic. Note was shutting down and it said something blah blah blah which is not closed but open. What's actually going on here? Our hopper nodes are running an indexer alongside you know their mixet operations. And it turned out that they got an event that told them close this

payment channel but they didn't know this payment channel was actually even even open right now. Right? Why? Because there was an event which was being swallowed. Right? So the node did not even get informed of this state update when parsing events. And you know I hear you well Sebastian why do you talk about isolated client bugs? This is boring. Move on already. Well, the truth is that every single one of your client teams finds themselves on this slide. This is a widespread issue all over the place that you know we spend a good amount of extremely annoying debugging time this summer on because you deal with like corrupt

databases. Do you know what you think when you face a corrupt database after one week of debugging? Because we debug the network stack. Okay. To get from a network stack to a corrupt database is a pain in the ass. To then from a corrupt database get to the point that actually an Ethereum client which is the holiest institution that we hold holy doesn't work. You know that's rough. That's not something you you would get to easily. So how did we get here? Egget logs is basically the basics of Ethereum, right?

It's Ethereum 101. It's standardized and this is the standard of ethloss. This is the execution layer specs only that this what we call specs here does not nearly cover any of the kind of more intricate cases like the ones I was just talking about. This is basically like a request response example which has indeed been very helpful to iron out stuff like you know incompatibilities of you know return codes and like types and stuff like that. that has been good but this is not a standard that helps us iron out these kinks that actual application developers are you know beating their head against the wall for yeah so this is a problem in lack of

standardization and you know you might say okay all this hopper stuff I don't really care about but arguably this is stuff that should work right this is something that Ethereum should deliver on like logs is not something very fancy And every single client developer, you know, as soon as I started like talking about this, there were a lot of people who reached out to me and who were like, Sebastian, I didn't know, you know, this was very surprising. I didn't think about this. I was facing all this broken And you know, I looked closer and indeed there were issues. Right now, the question is a little bit why is this hard? And I've already been talking about lack of standards, but I want to

give a bit of an example um that we've already heard before in Felix's talk, right? Felix talked about some new features that have recently been added to to GU. Many other clients did a similar thing. Who here in the room thinks that it is even a use case that we should support to index all ERC20 transfers to stick with this example from genesis to tip of the chain in low latency. Is that something that every client should support? Please raise your hand. Don't be shy. Yes, I'm asking for opinions and we try to be unopinionated in Ethereum. Okay, so I see a handful of hands up. So who here just the the opposite who here does not think that we should cater to this use case of you

know indexing events from genesis to tip hands up don't be shy no judgment I see slightly more hands up now but it was I would say 40 60 this is a problem okay this is a problem that even the most involved folks in the space do not have consensus on what a arguably very basic feature of Ethereum should actually cater to and the problem downstream of this is for application developers you know we had some folks actually in the privacy corner at at Devcon connect um Oxbow actually privacy rules love that stuff because they don't work with centralized indexers and they have been building this thing which

works on the client right which works like browser side and you as a user can go there and check your pool deposits and withdrawals they do all that stuff they do need long ranges for for events Right. So there is no understanding you know for even application developers even if they're very informed for what works and that is because we have a lack of standards in Ethereum land that is extremely widespread and even at the most important interface that you know application developers use that are supposedly supposed to bring us like a billion users or something right that is a problem. Now luckily there is extremely talented and you know very

well-meaning client developers that do solve that stuff right you work on that and a bunch of stuff does does get resolved I'm aware of that but like many times the issue is that lack of standards makes it hard and it leads to individual client teams implementing individual solutions and again Felix has been pointing out one which is building an index for locks which is cool but it's kind of wasteful if every client team has to work on their individual solution, right? But it's not just that they waste time on it. It's also that there's a trade-off space which is complex, right? And clients have to take decisions on and again just to make another poll to to gauge that here, right? Clients can optimize that and

Felix talked about you know how you increase the disk footprint a little bit and how GU made actually something that I really appreciate which is provability, right? But this shows one dimension of trade-off space, which is optimizing for disk footprint versus provability. And there's other dimensions, right? Like I don't care about any of that because I just want to run a validator. So I would like to just gauge some level of consensus. Again, who here thinks that, you know, all clients should support all these trade-off dimensions?

Whatever they are, we can, you know, agree on them. But you know, let's pick disk footprint provability versus uh you know, running a validator. Like should all Ethereum clients optimize for that? Please hands up. Okay. And now the opposite. Please hands up if you think that doesn't matter. You know, we can use some client for this, some other client for this. Who thinks we should do that? Damn, this is a better example than I thought it would be. So, we're again around 40 60. So this again shows me that this is a problem. Why is there a problem? Because I run a dot node at home, right? So in Ethereum kind of client diversity, right? So client diversity means if you

know Aragon up, I know Aragon is great, no offense, I can just spin up Nethermind G or you know what have you. If we run for optimizations that I cannot run because trust me I know what is the biggest hardware that I can buy as a retail pleb you know and I cannot run this really big stuff then I cannot switch then I do not actually have practical client diversity that is an issue and that's why I'm here talking about this that we should actually really address this at a high level all right now luckily it's not that bad and there's a great team which helps us on you know testing and all these called Panda Ops. Thank you Pari and

team for working on Hive. Right. So since I've been bitching about this topics, things got better. Even though you don't really see it here, trust me. So since I talked about this in September and you know I wrote this ETH research and was on the um ACD testing, things got basically much greener and we see many clients which improved quite a lot. Thank you for that. It really does make the life of application developers of Ethereum a lot better. Thank you. At [applause] at the same time, let's not applaud too early because there's plenty of work ahead. Anybody who is not working on Hive has a clue of how many kind of ETHG get logs, the primary thing I'm ranting

about tests we have in there. Okay, it's four. Why? Why? Why was somebody laughing? So yeah, I mean many of these four tests for several clients are currently not green. Okay, let's look at another number. Let's look at big brother literally. Let's look at the web, right? At the web. The web had the same damn issues that we are going through as an ecosystem growing up. And the web came together with a bunch of people through a bunch of painful interactions, standard setting and testing with the web platform tests. These are the results they are pulled from there. And

the only thing like you see the major browsers which run them, right? All of this stuff doesn't matter. I want you to look at this bottom number. It's a bunch of digits that are hard to read. This number is over 2 million tests. 2 million tests lead to me giving a presentation on some browser anywhere on the planet on somebody's damn computer and it works. This is the effect of standards. And if anybody thinks that browsers are more complex than Ethereum and that's why they need more tests, I'm happy to challenge you. You know, Ethereum can do a whole damn lot. And having something of under 200, you know, um client compat like RPC compatibility tests, um well, there's lots of room for

improvement here. Now, I hear you. Standards feels a bit like this, right? And I'm aware of it. But my point is if we do not seriously engage in standards, we will end up in a world where client developers have to engage in really annoying discussions on writing tests because you face opposition such as, "Oh, you guys just took the GU tests. We're not GE." And this is of course stupid because and they have good reasons and GU has good reasons. This is a lack of standards and as the impact of lack of standards in a developer's real life. If we don't have that, we have no visibility on Ethereum being broken and

me having to give talks while you would rather listen to something from the bleeding edge of Ethereum. Sorry for that. So basically I am wrapping up with what do we need? We need to establish consensus what the hell Ethereum execution layer clients are even supposed to be for and optimized for. Seconds, we need a commitment to standardize the RPC layer. And I heard that you have hired some folks here. Fantastic. I love it. But I think it needs really dedicated team and ownership and community engagement because we're talking about orders of magnitude improvement from 200 to 2 million tests. I don't know where the exact number is. I don't care. It's not 200. Okay? We need an orders of

magnitude change and that needs structural change. So finally I think we need to have a conversation of how we enforce these standards. I don't know what that is but like standards need some level of you know I don't know like we have a central body which the web did not have. The web did not have a wellunded Ethereum foundation. Yeah. So we are in a good position. Anyway I would like to uh finish this by saying taking action is punk. doing something and caring is punk. Ethereum needs standards punk. Thank you very much. [applause] [applause]

Well, thank you Sebastian here. Uh it seems like everybody was very attentive and listening to you here that no one has submitted questions yet. Um and so what I might do here is thank you very much for being the presenter and I would encourage everyone to speak to Sebastian at lunch here. two items that at least came to my mind is um after your talk is well then um you know what should be done right now and who should do it. So I encourage folks to uh ask those questions to you at the next uh lunch break. >> Yeah, happy to talk about that oneonone.

>> Thank you. >> [applause]