Fonctionnement des propositions d'amélioration d'Ethereum (EIP)

Fonctionnement des propositions d'amélioration d'Ethereum (EIP). Pour bien comprendre la nécessité de normes ERC (Ethereum Request for Comments), vous devez comprendre comment les mises à jour, les mises à niveau et les modifications de code ont lieu dans Ethereum.
Ethereum Improvement Propositions (EIP) décrivent les normes pour la plate-forme Ethereum, y compris les spécifications de protocole de base, les API client et les normes contractuelles. Ceux-ci sont proposés par n'importe quel membre de la communauté Ethereum, puis discutés à l'interne.
Ce n'est qu'après avoir pleinement compris le lien entre les EIP et les ERC que vous pourrez comprendre le fonctionnement des ERC. Donc, les premières choses d'abord.
Types EIP
Avant de plonger dans ce que signifie le statut EIP, vous devez comprendre quel est le but de chaque type EIP et pourquoi il existe une grande variété d'entre eux.
Standard Track : Cette description décrit toute modification qui affecte la plupart ou l'ensemble des implémentations Ethereum, telle qu'une modification du protocole réseau, une modification des règles de validité des blocs ou des transactions, des normes/conventions d'application proposées, ou tout changement ou ajout affectant l'interopérabilité des applications à l'aide de Ethereum.
Core : Il s'agit des améliorations nécessitant un fork consensuel (comme EIP5 et EIP101), ainsi que des changements qui ne sont pas nécessairement essentiels au consensus, mais qui peuvent être pertinents pour les discussions sur le « développement de base » (par exemple, les modifications 2, 3 et 4 de la stratégie mineur/nœud).
Mise en réseau : Cela inclut des améliorations autour de devp2p (EIP8) et du sous-protocole Light Ethereum, ainsi que des améliorations proposées aux spécifications de protocole réseau de Whisper et Swarm.
Interface : Il s'agit d'améliorations concernant les spécifications et les normes IPV/RPC des clients, ainsi que certaines normes au niveau de la langue comme les noms de méthodes (EIP6) et les IBA contractuels. L'étiquette « interface » s'aligne sur le dépôt de l'interface et la discussion devrait se produire principalement dans ce référentiel avant qu'un EIP ne soit soumis au référentiel EIP.
ERC : Il s'agit de normes et de conventions au niveau de l'application, y compris les normes contractuelles telles que les normes de jeton (ERC20), les registres de noms (ERC137), les systèmes d'URI (ERC681), les formats bibliothèque/paquet (EIP190) et les formats de portefeuille (EIP85).
Méta : Ceci décrit un processus entourant Ethereum ou qui propose une modification (ou un événement dans) un processus. Les EIP de processus sont comme les EIP de piste standard, mais s'appliquent à d'autres domaines que le protocole Ethereum lui-même. Ils peuvent proposer une implémentation, mais pas à la base de code d'Ethereum. Ils exigent souvent un consensus communautaire. Contrairement aux EIP informationnels, ils sont plus que des recommandations et les utilisateurs ne sont généralement pas libres de les ignorer. Par exemple, on peut citer les procédures, les lignes directrices, les changements apportés au processus décisionnel et les changements apportés aux outils ou à l'environnement utilisés dans le développement d'Ethereum. Tout méta EIP est également considéré comme un processus EIP.
Information : Ce type d'EIP décrit un problème de conception d'Ethereum, ou fournit des directives générales ou des informations à la communauté Ethereum, mais ne propose pas de nouvelle fonctionnalité. Les EIP informationnels ne représentent pas nécessairement un consensus ou une recommandation de la communauté Ethereum, de sorte que les utilisateurs et les implémenteurs sont libres d'ignorer les EIP informationnels ou de suivre leurs conseils.
Conditions d'état EIP
Il y a beaucoup de choses à comprendre si vous voulez bien comprendre quels PIE sont mis en œuvre, quels ERC sont incorporés sur chacun d'eux et, bien sûr, quels sont ceux qui sont définitifs et en vigueur. Les statuts EIP les plus importants sont :
Ébauche - un PIE qui est ouvert à l'examen et qui fait l'objet d'une itération et de changements rapides.
Last Call - un EIP qui est fait avec son itération initiale et prêt à être examiné par un large public.
Accepté - un EIP de base qui est dans le dernier appel depuis au moins deux semaines et toutes les modifications techniques demandées ont été traitées par l'auteur. Le processus permettant aux développeurs principaux de décider s'il faut encoder un EIP dans leurs clients dans le cadre d'une fourche dure ne fait pas partie du processus EIP. Si une telle décision est prise, le PPE passera à Final.
Final (non-core) - un EIP qui est dans le dernier appel depuis au moins deux semaines et toutes les modifications techniques demandées ont été traitées par l'auteur.
Final (Core) - un EIP que les développeurs de base ont décidé d'implémenter et de libérer dans une future fourche dure ou a déjà été publié dans une fourche dure.
Reporté - un PPE dont l'adoption immédiate n'est pas envisagée. Peut être reconsidéré à l'avenir pour une fourche dure subséquente.
Dans le prochain guide, j'examinerai les différents CEE, leur fonctionnement, leur but, les multiples types de normes qui existent et la façon dont elles peuvent être utilisées.
Restez à l'écoute.