Les ERC à l'état Final peuvent-ils établir un statut orthodoxe ?

Rédaction : Zhixiong Pan

Ces derniers temps, les discussions autour de l'ERC-6551 gagnent en intensité. Des sujets tels que « donner de nouveaux cas d'usage aux ERC-721 », « la spéculation autour des NFT utilisant ERC-6551 » ou encore « la mise en œuvre après intégration de l'ERC » attirent une attention croissante. Pourtant, je pense que le point clé ne réside pas tant dans cette norme elle-même, mais plutôt dans la compréhension de ce que représente un ERC sur Ethereum : est-ce la source de la légitimité communautaire ?

Je n’entrerai pas ici dans les détails du contexte de l’ERC-6551. En bref, il s’agit d’une norme de contrat intelligent permettant aux NFT de détenir d’autres actifs, ouvrant ainsi la voie à de nouveaux cas d’utilisation.

Connaissance utile 1 : Les ERC sont des standards applicatifs, qui n’impliquent pas directement le protocole Ethereum lui-même.

Les propositions d'amélioration d'Ethereum (EIP) sont clairement divisées en trois grandes catégories dans l'EIP-1 : les EIP de standardisation, les EIP méta et les EIP informatifs.

Parmi celles-ci, les EIP de standardisation sont les plus courantes. Elles comprennent les améliorations du noyau (Core), les améliorations de couche réseau (Networking), les améliorations d'interface (Interface) et les standards applicatifs (ERC).

Plus précisément, le standard ERC-6551 définit un contrat intelligent de registre, une interface d'implémentation de compte, ainsi qu'une implémentation de référence pour ces deux composants. Par exemple, le contrat de registre défini par l'ERC-6551 doit simplement inclure deux fonctions : créer un compte et lire son adresse. Quant à leur implémentation concrète, l'ERC-6551 fournit une proposition de référence.

Prenons le cas du standard de jeton le plus utilisé sur Ethereum : l'ERC-20. Il définit un ensemble d'interfaces de base que les développeurs peuvent implémenter selon leurs besoins, ou utiliser directement via des contrats open source comme ceux d'OpenZeppelin.

Connaissance utile 2 : Les propositions EIP ou ERC suivent une convention d'écriture précise (voir le document EIP-1). Il ne s'agit pas d'écrire « ERC XXX » ou « ERCXXX », mais bien « ERC-XXX ». De même pour les autres EIP non ERC : on écrit toujours EIP-XXX.

Par exemple, ERC-20, ERC-6551, EIP-3540.

Étant donné que l'ERC-6551 est une norme réalisable via des contrats intelligents, les développeurs auraient pu implémenter des fonctionnalités similaires avant même son apparition. Toutefois, avec cette norme, il devient possible de construire un écosystème plus vaste — par exemple, en facilitant le support par les portefeuilles et les marchés de transactions.

Sans l'ERC-4337, chaque portefeuille pourrait certes implémenter sa propre version d'un contrat intelligent pour l'abstraction des comptes, mais cela nuirait à la composable inter-portefeuilles et inter-applications. Sans l'ERC-20, chaque développeur pourrait aussi créer son propre jeton, mais les portefeuilles devraient alors intégrer manuellement chaque nouveau jeton, entraînant des coûts de développement inutiles.

Cependant, cela ne signifie pas que « devenir un standard ERC » soit la voie obligatoire vers le statut de standard industriel. Car par rapport à un ERC dans l'état « Final », la « consensus social » et le « standard de fait » sont bien plus importants.

Certains pensent peut-être qu’un standard industriel doit passer par une revue de la Fondation Ethereum ou de l’équipe d’édition des EIP et atteindre l’état « Final » pour être reconnu. En réalité, certains standards officiels restent peu utilisés, tandis que certaines pratiques non normalisées peuvent devenir des standards de fait grâce à l’émergence d’un consensus social.

Le cas des NFT en est un bon exemple : ils ont d’abord été mis en œuvre dans des applications, puis un standard ERC a été formalisé a posteriori. L’ERC-721 n’a été soumis qu’en janvier 2018 et n’est passé à l’état « Final » qu’en juin de la même année. Pourtant, le jeu CryptoKitties était déjà lancé fin 2017, et est largement reconnu comme la première application utilisant le standard ERC-721.

Ainsi, la logique ne devrait pas être « parce que l’ERC-721 est devenu un standard, un écosystème et une légitimité en sont nés », mais plutôt « parce qu’il existait une demande pour des jetons non fongibles, CryptoKitties a résolu ce problème, et le standard ERC-721 a permis de répondre efficacement à cette demande, ce qui a conduit la communauté à l’adopter ». Cela explique également pourquoi d’autres standards sont apparus par la suite, comme l’ERC-1155, afin de répondre à des besoins plus variés.

En résumé, les deux scénarios suivants sont possibles, mais le second correspond probablement mieux à la réalité :

1. Définir un standard => Écosystème

2. Identifier un besoin => Proposer une solution => Formaliser un standard => Écosystème

Quel que soit le chemin suivi, l’essentiel est de répondre à un besoin utilisateur et de permettre une adoption large et généralisée de la solution. Tel est le véritable objectif derrière l’introduction d’un nouveau standard.