Les ARCs, c'est quoi ?
À l'instar des ERCs sur Ethereum, apprenez-en plus sur les ARCs.
Last updated
À l'instar des ERCs sur Ethereum, apprenez-en plus sur les ARCs.
Last updated
Les ARCs (Algorand Request for Comments) sont des normes ou des standards techniques utilisés pour créer et implémenter de nouvelles fonctionnalités sur la blockchain d'Algorand.
Plus précisément, un ARC est un document de conception fournissant des informations à la communauté Algorand ou qui décrit une nouvelle fonctionnalité pour Algorand ou ses processus ou son environnement.
L'ARC doit fournir une spécification technique concise et une justification de la fonctionnalité.
L'auteur d'un ARC est responsable de la recherche d'un consensus au sein de la communauté, c'est-à-dire que la communauté doit se mettre d'accord sur sa proposition, et il doit également s'occuper de la documentation des opinions dissidentes à sa proposition.
La fondation Algorand souhaite que les ARCs soient les principaux mécanismes de proposition de nouvelles fonctionnalités et de collecte des commentaires techniques de la communauté Algorand sur un problème.
Les ARCs prennent la forme de fichiers texte dans un répertoire avec des versions et leur historique de révisions est l'enregistrement de l'évolution de la proposition de fonctionnalité.
Il existe trois types d'ARC:
L'ARC de suivi de norme (Standards track ARC): Il s'agit de normes et de conventions au niveau de l'application, y compris les normes contractuelles telles que les normes NFT par exemple, Algorand ABI, les schémas d'URl, les formats de bibliothèque/paquets et les formats de portefeuille.
L'ARC de processus (Meta ARC): Un ARC de processus décrit un processus entourant Algorand ou qui propose une modification (ou un événement) dans un processus. Les ARCs de processus sont comme les ARCs de suivi des normes, mais s'appliquent à des domaines autres que le protocole Algorand. Ils peuvent proposer une implémentation, mais pas à la base du code d'Algorand qui lui nécessite souvent un consensus communautaire. Contrairement aux ARCs informatifs, ils sont plus que des recommandations et les utilisateurs ne sont généralement pas libres de les ignorer. Les exemples incluent les procédures, les lignes directrices, les modifications apportées au processus de prise de décision et les modifications apportées aux outils ou à l'environnement utilisés dans le développement d'Algorand.
L'ARC informatif (Informational ARC): Un ARC d'information décrit soit un problème de conception d'Algorand, soit fournit des directives générales ou alors donne des informations à la communauté d'Algorand mais ile ne propose pas de nouvelle fonctionnalité. Les ARC informatifs ne représentent pas nécessairement le consensus de la communauté Algorand ou une recommandation, ce qui fait que les utilisateurs et les implémenteurs sont libres d'ignorer ou non les ARC informatifs ou de suivre leurs conseils.
Un ARC doit contenir une seule proposition clé ou une nouvelle idée.
Les parties impliquées dans le processus d'un ARC sont l'auteur de l'ARC, les éditeurs de l'ARC (voyez-les comme une sorte de modérateurs) et les développeurs principaux d'Algorand.
Il est recommandé que l'ARC soit le plus ciblé possible et doit concerné un changement qui affecte plusieurs clients, ou alors qui définit une norme pour plusieurs applications à utiliser.
Un ARC doit répondre à des critères minimaux spécifiques. Il doit s'agir d'une description claire et complète de l'amélioration proposée. L'amélioration doit représenter une amélioration nette. Le cas échéant, l'implémentation proposée doit être solide et ne pas compliquer outre mesure le protocole.
Avant d'écrire un ARC formel, il est recommandé à l'auteur de vérifier en premier lieu son idée auprès de la communauté Algorand, sur le forum ou sur Discord par exemple, pour éviter de perdre du temps sur quelque chose qui sera rejeté sur la base de recherches antérieures.
Lorsque l'idée est approuvée par la communauté, l'auteur peut commencer à travailler sur la proposition et la documentation de son ARC.
Le processus d'un ARC est long, strictement codifié et rigoureux.
Il se déroule en plusieurs étapes:
Idée (Idea) - Une idée qui est pré-ébauche. Cela n'est pas suivi dans le référentiel ARC.
Ébauche (Draft) - La première étape formellement suivie d'un ARC en développement. Un ARC est fusionné par un éditeur ARC dans le référentiel ARC lorsqu'il est correctement formaté.
Examen (Review) - Un auteur d'ARC marque un ARC comme étant prêt pour et demande un examen.
Dernier appel (Last Call) - La fenêtre de révision finale pour un ARC avant de passer au stade final. Un éditeur ARC attribuera le statut de dernier appel et définira une date de fin de révision généralement un mois plus tard.
Si cette période entraîne un changement normatif nécessaire, elle ramènera l'ARC à l'étape d'examen.
Final - Cet ARC représente la norme finale. Un ARC final existe dans un état de finalité et ne doit être mis à jour que pour corriger des erreurs et ajouter des clarifications non normatives.
Stagnant - Tout ARC au stade d'ébauche ou d'examen, s'il est inactif pendant 6 mois ou plus, est déplacé vers la catérogie stagnant. Un ARC peut être ressuscité à partir de cet état par les auteurs ou les éditeurs d'ARC en le ramenant au stade d'ébauche.
Les auteurs d'ARC sont informés de tout changement algorithmique du statut de leur ARC.
Retiré (Withdrawn) - Le ou les auteurs de l'ARC ont retiré l'ARC proposé. Cet état a une finalité et ne peut plus être ressuscité en utilisant ce numéro ARC. Si l'idée est poursuivie plus tard, elle est considérée comme une nouvelle proposition.
Vivant (Living) - Un statut spécial pour les ARC qui, par conception, sera continuellement mis à jour et n'atteindra pas un état de finalité.
Vous pouvez retrouver toutes les informations et des explications plus détaillés ICI.
