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

For Ether For me, slow development is a feature, not a bug. For a settlement layer that safeguards trillions of dollars in assets, it’s dangerous to move too fast.

Client diversity is important, but I agree that we may actually need fewer client teams. Also, I don't think client team coordination is the main bottleneck in developing new features; there are many other factors to consider, especially when it comes to backwards compatibility.

I would like to make three additional points here:

1. The infrastructure needs to adapt to Layer 2 changes faster, otherwise the Ethereum ecosystem will The whole risks losing its appeal.

There is a general expectation that Layer 2 solutions will develop faster. However, this is challenging because much of the infrastructure is slow to adapt. Even though Scroll has full EVM compatibility, we ran into issues with MetaMask:

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

This creates a tricky chicken-and-egg problem:

If Layer 1 does not change, infrastructure providers have no incentive to update. Without updated infrastructure, Layer 2 solutions cannot evolve faster, stifling innovation. This is a particular challenge for Ethereum, as most other chains have native wallets that are closely tied to chain upgrades. In contrast, the EVM standard follows Ethereum, which complicates adaptation.

2. Specifications are crucial, and all current Layer 2 solutions lack specifications

In order to achieve client diversity, we need more complete specifications. However, many teams claim to have multi-client implementations but actually have a fundamental misunderstanding of the concept.

The correct approach should be:

1. Define high-level specifications.

2. Ensure that any team can implement the feature by reading the specifications without referring to other clients Implementation.

That is, the only source of truth for a multi-client implementation should be the specification itself, but currently, most implementations rely on existing implementations as a reference. Defies the true potential of multi-client architecture

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

Bitcoin relies on a single implementation as its source of truth, with the core codebase being the only truth and incapable of error.

The true 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, the problem should be corrected according to the specification through social consensus rather than relying on a specific implementation.