Scroll Co-Creation: The "Chicken and Egg" Problem of the Ecological Development of ETH Square

Author: Ye Zhang Source: X, @yezhang1998 Translation: Shanooba, Golden Finance

For Ethereum, slow development is a feature, not a flaw. For a settlement layer that safeguards trillions of dollars in assets, rapid development is dangerous.

Client diversity is important, but I agree that we may actually need fewer client teams. Also, I don’t think the coordination of client teams is the main bottleneck for developing new features; there are many other factors to consider, especially in terms of backward compatibility.

I want to raise three additional points here:

1. The infrastructure needs to adapt to the changes in Layer 2 faster, otherwise there is a risk of losing attractiveness for the overall Ethereum ecosystem.

There is a general expectation that Layer 2 solutions will develop faster. However, this is challenging because many infrastructures are slow to adapt. Even though Scroll has full EVM compatibility, we have encountered issues with MetaMask:

The transaction fees for Scroll (or any other Layer 2) include data availability (DA) fees and execution fees, but MetaMask only supports execution fees by default, resulting in incorrect fee calculations for several months.

This has created a tricky chicken-and-egg situation:

If Layer 1 doesn’t change, infrastructure providers have no incentive to update. Without updated infrastructure, Layer 2 solutions cannot develop faster, thus stifling innovation. This is a unique challenge for Ethereum, as most other chains have native wallets closely tied to chain upgrades. In contrast, the EVM standard follows Ethereum, making adaptation more complex.

2. Standardization is crucial, and currently all Layer 2 solutions lack standardization

In order to achieve client diversity, we need more comprehensive specifications. However, many teams claim to have multiple client implementations, but in reality, there is a fundamental misunderstanding of this concept.

The correct approach should be:

1. Define high-level specifications.

2. Ensure that any team can implement the function by reading the specification without referring to other client implementations.

In other words, the only true source of multi-client implementation should be the specification itself. However, currently, most implementations rely on existing implementations as a reference, which violates the true potential of multi-client architecture.

3. It is also important to note the differences between Ethereum and Bitcoin

Bitcoin relies on a single implementation as its true source, and the core codebase is the only truth that cannot go wrong.

But the real source of Ethereum is the specification itself, not a specific implementation like Geth.

This approach makes the specification more practical for Ethereum. If an error occurs, it should be corrected based on social consensus according to the specification, rather than relying on a specific implementation.