Ethereum's complexity is a more centralising force than the OG web

[mratsim]

I’ve read your previous criticism of ERC-4337 at Complaint - quality of writing in EIP-4337

What are you looking for in an EIP/ERC? The main target of ERCs are implementers, to make sure it’s obvious and clear how to conform to a standard.

You can use this as a reference to frame what you would like to see more in EIPs/ERCs; About | Divio Documentation especially this table

Today, I find myself particularly despondent contemplating whether Ethereum can really be the future of software in the way HTTP became the future in 1989; HyperText was fundamentally text based and extensible, and therefore a joy from day one, while Ethereum feels like a stack of workarounds that may rapidly become untenable.

Compared to the elegance and adaptability of the original web protocols, I find Ethereum esoteric and increasingly difficult to grasp, i.e. getting tougher, especially since Account Abstraction. The nature of the blockchain is challenging enough but the compounding complexity makes the system an almost vertical climb for newcomers and exhausting for experienced developers.

I disagree with this, I see seldom people even devs understanding the intricacies of TCP/IP, the TLS state machine, DNS, BGP, the OSI layers. Even if we stay just at the presentation layer, very few people understand what goes into a V8 JIT engine, the pile of React/Angular in the app, the caching in Akamai/Cloudflare and what not.

The core problem with Ethereum seems to be rooted in the protocol’s lack of extensibility. I wonder if the decision to use RLP for message encoding, rather than a more flexible self-describing format that can better tolerate the unknowable, has led to spiralling complications. Each EIP reads like a trick way to get around some past decision and together they resemble a tower of hacks to sniff bytes, wrap payloads within payloads and dodge bullets with binary.

RLP is self-describing instead of being schema-based or protocol-based. And it has been ditched from the consensus layer because self-describing are a waste of the most previous resource in blockchain, storage.

Importantly, each hack necessitates burdensome code that must be added, tested and maintained in apps, and this pain drives people to centralised libraries and service providers. I think nothing of preparing and shooting off my own HTTP requests, but I’ll happily pay a service to prepare and send a transaction or user operation. This situation is the very antithesis of Ethereum’s values. It’s a more centralising force than the original web and we’ll see giant companies who’s value is pain relief.

Do you have something in mind? Because EIPs are the burden of client teams which today are all open-source. ERCs are standards for interop between all industry players and having them promote the creation of open libraries instead of walled gardens.

This situation appears to stem from an extreme application of the YAGNI principle. I’m sympathetic that blockchains are severely resource constrained, but do we see this situation as permanent or will there come a time when the trade offs change and it can be reconceptualised? YAGNI is fine for private app code, but does it apply here? When designing the future of all connected software, you probably are going to need a lot of things that evade your imagination right now.

What are you referring to here? All EIPs need a champion or they won’t even get at the starting line. And even with strong advocates they might get delayed. See EIP-2537 for example.

@luke

Each improvement prioritises efficiency and frugality, apparently even in its writing, and I rarely read a discussion about how the proposal can be extended or could handle some hypothetical cases. Given that we now have a good idea of just how often “we do need it”, an Extensibility section might be a prudent mandatory addition to EIPs. Another useful section would be a Realworld Integration Example which would add much needed concretion to the abstract terminology and help it all “click” for people.

ERC-4337 is one of the rare proposal with a diagram flow:

For EIPs, they usually require a reference implementation along the proposal so people can evaluate the implementation risk and complexity as well, many of the prototypes are available in GitHub - ethereum/research for those proposed by the EF itself.

@luke

Today, Ethereum’s EIP quagmire feels too much like a “high WTFs per hour” codebase where team-mates churn due to years of untackled debt which repels the very people needed to reform it. As such, I also feel a Developer Pain section might also help authors think through the impact of their improvement on everyone else. This brings me back to the selfish writing: time saved by a few authors is time stolen from many thousands of readers. That must change.

Each EIP refers to this exact forum for discussion and clarification. When that discussion happens behind closed doors people complain that it’s not public, when it’s public, people complain that it needs to be refined and it steals time from people, despite being in draft. What do you prefer?

People rely on debt, you can’t produce software of that complexity without iterative improvement and deprecation, you would invalidate billions of dollars of hardwork otherwise.

I’m curious about the community’s thoughts on balancing efficiency with extensibility in protocol design, and how Ethereum might evolve to address these challenges. As it stands, it is a slog.

Ethereum seems to have the best balance of activity and extensibility as a protocol, but I may very well be biaised. What other protocols are you thinking of?