Scroll联创：Le dilemme du « œuf et de la poule » dans le développement de l'écosystème Éther

Auteur: Ye Zhang Source: X, @yezhang1998 Traduction: Shanooba, Golden Finance

Pour Ethereum, un développement lent est une caractéristique, pas un défaut. Pour une couche de règlement garantissant des milliards de dollars d'actifs, un développement trop rapide est dangereux.

La diversité des clients est importante, mais je suis d'accord, en réalité nous avons probablement besoin de moins d'équipes de clients. De plus, je ne pense pas que la coordination des équipes de clients soit le principal obstacle au développement de nouvelles fonctionnalités; il y a de nombreux autres facteurs à prendre en compte, en particulier en ce qui concerne la compatibilité ascendante.

Je voudrais soulever trois autres points ici :

1. Les infrastructures doivent s'adapter plus rapidement aux changements de la couche 2, sinon il y a un risque de perte d'attrait pour l'écosystème Ethereum dans son ensemble.

Les gens s'attendent généralement à ce que les solutions Layer 2 se développent plus rapidement. Cependant, cela est très difficile car de nombreuses infrastructures s'adaptent lentement. Même si Scroll est entièrement compatible avec l'EVM, nous rencontrons des problèmes avec MetaMask :

Les frais de transaction de Scroll (ou de tout autre couche 2) comprennent les frais de disponibilité des données (DA) et les frais d'exécution, mais MetaMask ne prend en charge que les frais d'exécution par défaut, ce qui a entraîné des calculs de frais incorrects depuis plusieurs mois.

Cela crée un problème épineux de savoir qui est apparu en premier, la poule ou l'œuf:

Si Layer 1 ne change pas, les fournisseurs d'infrastructure n'ont pas la motivation de mettre à jour. Sans une infrastructure mise à jour, les solutions de Layer 2 ne peuvent pas se développer plus rapidement, ce qui étouffe l'innovation. C'est un défi particulier pour Ethereum car la plupart des autres chaînes ont des portefeuilles natifs étroitement liés à la mise à niveau de la chaîne. En revanche, la norme EVM suit Ethereum, ce qui rend l'adaptation compliquée.

2. Il est essentiel d'avoir des normes, mais actuellement toutes les solutions Layer 2 manquent de normes

Pour assurer la diversité des clients, nous avons besoin de spécifications plus complètes. Cependant, de nombreuses équipes prétendent avoir une implémentation multi-client, mais en réalité, elles ont une compréhension fondamentalement erronée de ce concept. Veuillez fournir le texte source à traduire. La bonne approche devrait être :

1. Définir des spécifications de haut niveau.

2. Assurez-vous que toute équipe peut implémenter cette fonctionnalité en lisant les spécifications sans avoir à se référer à une autre implémentation client.

En d'autres termes, la seule source réelle d'implémentation multi-clients devrait être la spécification elle-même. Cependant, la plupart des implémentations actuelles dépendent des implémentations existantes comme référence, ce qui va à l'encontre du véritable potentiel de l'architecture multi-clients.

3. Il est également important de noter les différences entre Ethereum et Bitcoin

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

La vraie source d'Ethereum est la spécification elle-même, pas une implémentation spécifique comme Geth. Veuillez fournir le texte source à traduire. Cette méthode rend les spécifications plus significatives pour Ethereum. En cas d'erreur, il convient de corriger le problème selon le consensus social, conformément aux spécifications, plutôt que de compter sur une implémentation spécifique.