Le 30 novembre 2023, les développeurs d’Ethereum se sont réunis sur Zoom pour la réunion #122 de l’appel All Core Developers Consensus (ACDC). La conférence téléphonique de l’ACDC est une série de réunions bihebdomadaires modérées par Danny Ryan, chercheur à la Fondation Ethereum, au cours desquelles les développeurs discutent et coordonnent les modifications apportées à la couche de consensus (CL) d’Ethereum. Cette semaine, les développeurs se sont concentrés sur les derniers développements en matière de tests Cancun/Deneb, notamment :
· Lancement de Devnet #12 : Les tests des logiciels clients Teku, Lodestar et Lighthouse sur Devnet #12, ainsi que de tous les logiciels clients de la couche d’exécution (EL), sont en cours. L’équipe de Prysm s’attend à ce que son logiciel soit prêt à être testé d’ici deux à trois semaines sur la dernière version de Devnet.
· Problème de sortie du validateur sur Devnet #11 : Au Devnet #11, les développeurs ont identifié un problème lié à la sortie du validateur, qui est actuellement en cours de résolution par l’équipe client Nimbus. Devnet #11 continuera à fonctionner normalement jusqu’à ce que le problème soit résolu.
· Clarification de la spécification réseau : les développeurs ont discuté de la clarification de la spécification pour les requêtes « BlockByRoot » et « BlobSidecarsByRoot », en précisant si les nœuds de couche de consensus (CL) doivent répondre à ces demandes dans un ordre spécifique.
En plus de la mise à jour Cancun/Deneb, les développeurs ont discuté de certains des problèmes de processus soulevés par Tim Beiko, responsable du support des protocoles de la Fondation Ethereum, afin d’améliorer la coordination de la mise à niveau d’Ethereum.
Réseau de développement #12
Le mercredi 30 novembre 2023, la mise à niveau Cancun/Deneb a été officiellement lancée sur Devnet #12. Mario Vega, de l’équipe de test de la Fondation Ethereum, a déclaré qu'"aucun problème majeur n’a été identifié à ce jour » dans les trois clients CL actuellement en cours d’exécution sur le réseau de test. Barnabas Busa, ingénieur DevOps à la Fondation, a mentionné qu’il y a un total de 225 validateurs répartis sur trois nœuds entre Lighthouse, Teku et Lodestar. En raison de la stabilité de Devnet #12, Parithosh Jayanthi, un ingénieur DevOps de la Fondation, a demandé aux développeurs s’ils devaient commencer à planifier un shadow fork de Goerli pour tester davantage Cancun/Deneb. Cependant, étant donné que Prysm, le client CL le plus populaire à l’heure actuelle, n’a pas encore rejoint Devnet #12, les développeurs ont décidé de mettre en attente les plans d’un shadow fork de Goerli jusqu’à ce que le logiciel client Prysm soit prêt à être testé. Beiko suggère de passer à la bifurcation de l’ombre de Goerli avant la fin de l’année. En raison de la stabilité de Devnet #12, les plans sont mis en attente jusqu’à ce que le logiciel client Prysm soit prêt à être testé.
Réseau de développement #11
Le développeur de Nimbus, qui se fait appeler « Dustin », partage les détails du problème Devnet #11 sur lequel son équipe travaille. Ces problèmes ont été découverts pour la première fois lorsqu’un développeur a quitté un tiers des validateurs de Devnet #11 pour les utiliser sur Devnet #12. Ryan demande à Dustin s’il peut repérer ces problèmes avec des tests supplémentaires. Dustin a répondu qu’à son avis, la nature de ces erreurs était causée par des détails de mise en œuvre qui dépassaient le cadre de la spécification consensuelle. Cependant, il reconnaît également qu’il existe une « tension claire » entre l’écriture d’un logiciel client strictement conforme à la spécification CL afin de tester les avantages de la couverture et le fait de patauger dans les zones grises de la spécification afin d’obtenir de meilleures performances de nœud.
« Je veux dire qu’il est toujours bon d’avoir plus de tests, mais trouver plus systématiquement comment intégrer plus de fonctionnalités côté client dans l’exécution des tests est peut-être plus automatisé, qu’il s’agisse d’utiliser Hive, Kurtosis ou autre. Je pense qu’il serait certainement utile que ces problèmes puissent être résolus ou que les choses puissent être décomposées suffisamment bien pour pouvoir intégrer davantage de ces tâches », a ajouté Dustin, ajoutant qu’un autre défi que les développeurs de CL devraient envisager de relever est de déterminer le niveau de détail que la spécification CL devrait dicter et normaliser le comportement des nœuds. « L’autre défi ici est le degré de standardisation, qui n’est pas seulement une question d’ingénierie logicielle, à quel point le comportement devrait-il être standardisé ? » Demanda Dustin. Tous les clients CL réussissent des tests qui vérifient le comportement de base, mais le comportement en dehors de la portée de ces tests est ambigu. « Est-ce que ce sont des choses délibérément vagues ? Qu’est-ce qui devrait être vraiment clair par la norme et qu’est-ce qui devrait être délibérément obscur ? Demanda Dustin.
À tout le moins, les développeurs ont convenu d’ajouter plus de tests aux futurs réseaux de développement et de test pour un grand nombre de sorties de validateurs à Cancun/Deneb. Ryan reconnaît également qu’il est possible d’offrir une couverture de tests plus rigoureuse et plus complète en ce qui concerne les clients CL et la mise en œuvre des spécifications CL. Vega a suggéré à Dustin de créer un article sur HackMD détaillant ses préoccupations et de discuter du sujet lors du prochain appel test Cancun/Deneb. Jayanthi a ajouté que, sur la base de certains des problèmes récemment identifiés sur les réseaux Devnets Cancun/Deneb, il existe un besoin évident pour les développeurs de disposer d’outils capables d’effectuer systématiquement un certain nombre de comportements liés à l’intégration on-chain, tels que le staking des retraits d’ETH, les retraits de validateurs, etc. Pour ce faire, Jayanthi recommande de créer un tel outil à l’aide d’un mélange de suites de tests Hive et Kurtosis.
S’exprimant sur le nouvel outil de test pour la mise à niveau Cancun/Deneb, Jayanthi a noté que les développeurs travaillent sur un outil permettant d’activer de manière fiable les réunions de chaîne sur les réseaux de développement et de test. Pour s’assurer que cet outil fonctionne, Jayanthi a demandé aux développeurs de partager les détails des bogues connus qui ont déclenché des réorganisations de chaînes sur Ethereum. Jayanthi a expliqué qu’il utilisera ces bogues pour tester l’outil et s’assurer qu’il peut identifier de manière fiable quand une réorganisation se produit et quand elle est résolue.
Clarification des spécifications du réseau
Les développeurs ont brièvement discuté d’une demande de tirage ouverte proposée par Justin Traglia, chercheur à la Fondation Ethereum, concernant l’ordre des réponses que les clients CL doivent renvoyer lorsqu’ils reçoivent une requête « BlockbyRoot » ou « BlobSidecarsByRoot ». Ryan demande comment les différentes équipes clientes de CL mettent déjà en œuvre cette fonctionnalité. Aucun des développeurs participant à l’appel n’a répondu à cette question. Ryan a suggéré de relancer la discussion sur le canal Discord d’Ethereum Research & Development pour impliquer un plus large éventail de développeurs clients. Ryan reconnaît qu’il y a des ambiguïtés dans les spécifications des deux demandes, qui « peuvent être à l’origine de problèmes et de cas limites étranges » et « méritent d’être clarifiées et réglées », affirme Ryan.
Ryan a également mentionné qu’il publiera une nouvelle version de la spécification CL dans les prochains jours. La dernière version ajoute de manière significative des spécifications sur le moment où un client CL peut fournir des blocs et des blocs via une requête RPC « byRoot ». Pour plus d’informations sur la discussion sur la récupération des blocs manquants et des blocs via des requêtes RPC « byRoot », veuillez vous référer au journal des appels précédent. Ryan souligne que les nouveaux ajouts à la spécification CL inclus dans la dernière version n’auront pas de modifications cassantes au code qui affectent le code pour les validateurs déjà en cours d’exécution sur Devnet #11 ou #12.
Processus de planification de la mise à niveau
Ensuite, les développeurs ont discuté des différents éléments de processus proposés par Beiko. Beiko a déclaré qu’un article de blog avertissant les utilisateurs du réseau de test Goerli de l’obsolescence imminente dans les 3 mois suivant l’activation de la mise à niveau Cancun/Deneb sur Goerli, ou 1 mois après l’activation de la mise à niveau sur le réseau principal Ethereum, selon la date la plus tardive, sera publié sur le blog de la Fondation Ethereum le 30 novembre. Depuis la fin de l’appel, l’article de blog ci-dessus a été publié et peut être lu ici.
Beiko suggère de créer un dossier spécifique à la mise à niveau sous le référentiel Ethereum « pm » pour organiser divers fichiers liés à une mise à niveau spécifique dans un seul dossier pour une utilisation ultérieure. Les développeurs présents à l’appel étaient d’accord avec la suggestion de Beiko.
Le deuxième élément du processus proposé par Beiko concerne la création d’un document « Meta EIP » pour suivre l’ensemble des mises à niveau du réseau qui ont été effectuées sur Ethereum. « Il n’y a pas de bon endroit pour suivre l’ensemble de la portée d’une mise à niveau réseau avant de la déployer et de l’annoncer dans un article de blog », a écrit Beiko dans un article sur sa proposition Meta EIP. « Pour Dencun, nous avons des EIP EL dans un fichier Markdown 7 difficile à trouver, et les EIP CL font partie de la spécification 3 de la chaîne de balises. Ce n’est pas génial, car les deux sont un peu difficiles à trouver, ils utilisent des « formats » différents et ils conduisent à des doublons. Étant donné que l’ERC et les EIP sont désormais séparés, je recommande (en revenant) d’utiliser les EIP Meta pour suivre les EIP inclus dans la mise à niveau du réseau. Les développeurs étaient favorables à la création de ces documents. Beiko a déclaré qu’il rédigerait un document pour l’examen de la mise à niveau de Cancun/Deneb cette semaine.
Enfin, Beiko a soulevé une question sur l’utilité de marquer les modifications de code proposées, les propositions d’amélioration d’Ethereum (EIP), comme « Consider Inclusion » (CFI). Selon Beiko, CFI est un statut que les développeurs ont historiquement utilisé comme un « signal doux », indiquant que les auteurs de l’EIP devraient continuer à travailler sur des propositions qui pourraient être incluses dans de futurs hard forks. Il n’est utilisé que pour les modifications et les mises à niveau de code axées sur EL. 「[CFI] plus élevé que les idées aléatoires de personnes aléatoires, mais avant qu’elles ne soient acceptées dans le fork », a déclaré Beiko.
Dans le passé, l’étiquetage des IFC n’a fait que peu ou pas d’efforts pour indiquer quels EIP de la LE seront mis en œuvre dans le cadre de la mise à niveau, ou quand. Il a été appliqué à un large éventail d’EIP avec différents degrés de préparation du code et de soutien de la part des équipes clientes. Dans le cas de la proposition de format d’objet EVM (EOF), les développeurs utilisent cette balise pour indiquer leur engagement à mettre en œuvre EOF dans la prochaine mise à niveau à venir, Cancun/Deneb. Cependant, l’EOF, ainsi que plusieurs autres propositions qui sont également signalées comme CFI, ont été rejetées par Cancun/Deneb, et il n’est pas clair quel est le statut de ces EIP marqués comme CFI dans la prochaine mise à niveau Prague/Electra.
Beiko a déclaré que si cet état n’aide pas, les développeurs devraient le supprimer, mais s’ils ont l’intention de le conserver, les développeurs CL devraient également utiliser la même étiquette sur les changements de code qu’ils envisagent d’implémenter dans les mises à niveau CL. Il n’est pas clair dans quelle mesure le processus d’examen du PIE du CL reflète le processus d’examen du PIE du CL et s’il devrait évoluer de la même manière à l’avenir. En règle générale, les modifications de code proposées à la spécification CL sont discutées lors de la conférence téléphonique de l’ACDC, tandis que les EIP proposés à la spécification EL sont discutés lors de la conférence téléphonique de l’ACDE.
Danno Ferrin, de Swirlds Labs, a également eu l’idée de créer un champ réservé pour tous les EIP, qu’ils soient liés à CL ou à EL, qui indique leur statut au cours du processus d’examen, y compris le statut de la FCI. Lors de cet appel, il n’y a pas eu de décision claire sur le sujet du statut EIP et de l’étiquetage CFI.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Résumé de la dernière réunion des développeurs principaux d’Ethereum : Devnet #12启动, processus de planification de la mise à niveau
Le 30 novembre 2023, les développeurs d’Ethereum se sont réunis sur Zoom pour la réunion #122 de l’appel All Core Developers Consensus (ACDC). La conférence téléphonique de l’ACDC est une série de réunions bihebdomadaires modérées par Danny Ryan, chercheur à la Fondation Ethereum, au cours desquelles les développeurs discutent et coordonnent les modifications apportées à la couche de consensus (CL) d’Ethereum. Cette semaine, les développeurs se sont concentrés sur les derniers développements en matière de tests Cancun/Deneb, notamment :
· Lancement de Devnet #12 : Les tests des logiciels clients Teku, Lodestar et Lighthouse sur Devnet #12, ainsi que de tous les logiciels clients de la couche d’exécution (EL), sont en cours. L’équipe de Prysm s’attend à ce que son logiciel soit prêt à être testé d’ici deux à trois semaines sur la dernière version de Devnet.
· Problème de sortie du validateur sur Devnet #11 : Au Devnet #11, les développeurs ont identifié un problème lié à la sortie du validateur, qui est actuellement en cours de résolution par l’équipe client Nimbus. Devnet #11 continuera à fonctionner normalement jusqu’à ce que le problème soit résolu.
· Clarification de la spécification réseau : les développeurs ont discuté de la clarification de la spécification pour les requêtes « BlockByRoot » et « BlobSidecarsByRoot », en précisant si les nœuds de couche de consensus (CL) doivent répondre à ces demandes dans un ordre spécifique.
En plus de la mise à jour Cancun/Deneb, les développeurs ont discuté de certains des problèmes de processus soulevés par Tim Beiko, responsable du support des protocoles de la Fondation Ethereum, afin d’améliorer la coordination de la mise à niveau d’Ethereum.
Réseau de développement #12
Le mercredi 30 novembre 2023, la mise à niveau Cancun/Deneb a été officiellement lancée sur Devnet #12. Mario Vega, de l’équipe de test de la Fondation Ethereum, a déclaré qu'"aucun problème majeur n’a été identifié à ce jour » dans les trois clients CL actuellement en cours d’exécution sur le réseau de test. Barnabas Busa, ingénieur DevOps à la Fondation, a mentionné qu’il y a un total de 225 validateurs répartis sur trois nœuds entre Lighthouse, Teku et Lodestar. En raison de la stabilité de Devnet #12, Parithosh Jayanthi, un ingénieur DevOps de la Fondation, a demandé aux développeurs s’ils devaient commencer à planifier un shadow fork de Goerli pour tester davantage Cancun/Deneb. Cependant, étant donné que Prysm, le client CL le plus populaire à l’heure actuelle, n’a pas encore rejoint Devnet #12, les développeurs ont décidé de mettre en attente les plans d’un shadow fork de Goerli jusqu’à ce que le logiciel client Prysm soit prêt à être testé. Beiko suggère de passer à la bifurcation de l’ombre de Goerli avant la fin de l’année. En raison de la stabilité de Devnet #12, les plans sont mis en attente jusqu’à ce que le logiciel client Prysm soit prêt à être testé.
Réseau de développement #11
Le développeur de Nimbus, qui se fait appeler « Dustin », partage les détails du problème Devnet #11 sur lequel son équipe travaille. Ces problèmes ont été découverts pour la première fois lorsqu’un développeur a quitté un tiers des validateurs de Devnet #11 pour les utiliser sur Devnet #12. Ryan demande à Dustin s’il peut repérer ces problèmes avec des tests supplémentaires. Dustin a répondu qu’à son avis, la nature de ces erreurs était causée par des détails de mise en œuvre qui dépassaient le cadre de la spécification consensuelle. Cependant, il reconnaît également qu’il existe une « tension claire » entre l’écriture d’un logiciel client strictement conforme à la spécification CL afin de tester les avantages de la couverture et le fait de patauger dans les zones grises de la spécification afin d’obtenir de meilleures performances de nœud.
« Je veux dire qu’il est toujours bon d’avoir plus de tests, mais trouver plus systématiquement comment intégrer plus de fonctionnalités côté client dans l’exécution des tests est peut-être plus automatisé, qu’il s’agisse d’utiliser Hive, Kurtosis ou autre. Je pense qu’il serait certainement utile que ces problèmes puissent être résolus ou que les choses puissent être décomposées suffisamment bien pour pouvoir intégrer davantage de ces tâches », a ajouté Dustin, ajoutant qu’un autre défi que les développeurs de CL devraient envisager de relever est de déterminer le niveau de détail que la spécification CL devrait dicter et normaliser le comportement des nœuds. « L’autre défi ici est le degré de standardisation, qui n’est pas seulement une question d’ingénierie logicielle, à quel point le comportement devrait-il être standardisé ? » Demanda Dustin. Tous les clients CL réussissent des tests qui vérifient le comportement de base, mais le comportement en dehors de la portée de ces tests est ambigu. « Est-ce que ce sont des choses délibérément vagues ? Qu’est-ce qui devrait être vraiment clair par la norme et qu’est-ce qui devrait être délibérément obscur ? Demanda Dustin.
À tout le moins, les développeurs ont convenu d’ajouter plus de tests aux futurs réseaux de développement et de test pour un grand nombre de sorties de validateurs à Cancun/Deneb. Ryan reconnaît également qu’il est possible d’offrir une couverture de tests plus rigoureuse et plus complète en ce qui concerne les clients CL et la mise en œuvre des spécifications CL. Vega a suggéré à Dustin de créer un article sur HackMD détaillant ses préoccupations et de discuter du sujet lors du prochain appel test Cancun/Deneb. Jayanthi a ajouté que, sur la base de certains des problèmes récemment identifiés sur les réseaux Devnets Cancun/Deneb, il existe un besoin évident pour les développeurs de disposer d’outils capables d’effectuer systématiquement un certain nombre de comportements liés à l’intégration on-chain, tels que le staking des retraits d’ETH, les retraits de validateurs, etc. Pour ce faire, Jayanthi recommande de créer un tel outil à l’aide d’un mélange de suites de tests Hive et Kurtosis.
S’exprimant sur le nouvel outil de test pour la mise à niveau Cancun/Deneb, Jayanthi a noté que les développeurs travaillent sur un outil permettant d’activer de manière fiable les réunions de chaîne sur les réseaux de développement et de test. Pour s’assurer que cet outil fonctionne, Jayanthi a demandé aux développeurs de partager les détails des bogues connus qui ont déclenché des réorganisations de chaînes sur Ethereum. Jayanthi a expliqué qu’il utilisera ces bogues pour tester l’outil et s’assurer qu’il peut identifier de manière fiable quand une réorganisation se produit et quand elle est résolue.
Clarification des spécifications du réseau
Les développeurs ont brièvement discuté d’une demande de tirage ouverte proposée par Justin Traglia, chercheur à la Fondation Ethereum, concernant l’ordre des réponses que les clients CL doivent renvoyer lorsqu’ils reçoivent une requête « BlockbyRoot » ou « BlobSidecarsByRoot ». Ryan demande comment les différentes équipes clientes de CL mettent déjà en œuvre cette fonctionnalité. Aucun des développeurs participant à l’appel n’a répondu à cette question. Ryan a suggéré de relancer la discussion sur le canal Discord d’Ethereum Research & Development pour impliquer un plus large éventail de développeurs clients. Ryan reconnaît qu’il y a des ambiguïtés dans les spécifications des deux demandes, qui « peuvent être à l’origine de problèmes et de cas limites étranges » et « méritent d’être clarifiées et réglées », affirme Ryan.
Ryan a également mentionné qu’il publiera une nouvelle version de la spécification CL dans les prochains jours. La dernière version ajoute de manière significative des spécifications sur le moment où un client CL peut fournir des blocs et des blocs via une requête RPC « byRoot ». Pour plus d’informations sur la discussion sur la récupération des blocs manquants et des blocs via des requêtes RPC « byRoot », veuillez vous référer au journal des appels précédent. Ryan souligne que les nouveaux ajouts à la spécification CL inclus dans la dernière version n’auront pas de modifications cassantes au code qui affectent le code pour les validateurs déjà en cours d’exécution sur Devnet #11 ou #12.
Processus de planification de la mise à niveau
Ensuite, les développeurs ont discuté des différents éléments de processus proposés par Beiko. Beiko a déclaré qu’un article de blog avertissant les utilisateurs du réseau de test Goerli de l’obsolescence imminente dans les 3 mois suivant l’activation de la mise à niveau Cancun/Deneb sur Goerli, ou 1 mois après l’activation de la mise à niveau sur le réseau principal Ethereum, selon la date la plus tardive, sera publié sur le blog de la Fondation Ethereum le 30 novembre. Depuis la fin de l’appel, l’article de blog ci-dessus a été publié et peut être lu ici.
Beiko suggère de créer un dossier spécifique à la mise à niveau sous le référentiel Ethereum « pm » pour organiser divers fichiers liés à une mise à niveau spécifique dans un seul dossier pour une utilisation ultérieure. Les développeurs présents à l’appel étaient d’accord avec la suggestion de Beiko.
Le deuxième élément du processus proposé par Beiko concerne la création d’un document « Meta EIP » pour suivre l’ensemble des mises à niveau du réseau qui ont été effectuées sur Ethereum. « Il n’y a pas de bon endroit pour suivre l’ensemble de la portée d’une mise à niveau réseau avant de la déployer et de l’annoncer dans un article de blog », a écrit Beiko dans un article sur sa proposition Meta EIP. « Pour Dencun, nous avons des EIP EL dans un fichier Markdown 7 difficile à trouver, et les EIP CL font partie de la spécification 3 de la chaîne de balises. Ce n’est pas génial, car les deux sont un peu difficiles à trouver, ils utilisent des « formats » différents et ils conduisent à des doublons. Étant donné que l’ERC et les EIP sont désormais séparés, je recommande (en revenant) d’utiliser les EIP Meta pour suivre les EIP inclus dans la mise à niveau du réseau. Les développeurs étaient favorables à la création de ces documents. Beiko a déclaré qu’il rédigerait un document pour l’examen de la mise à niveau de Cancun/Deneb cette semaine.
Enfin, Beiko a soulevé une question sur l’utilité de marquer les modifications de code proposées, les propositions d’amélioration d’Ethereum (EIP), comme « Consider Inclusion » (CFI). Selon Beiko, CFI est un statut que les développeurs ont historiquement utilisé comme un « signal doux », indiquant que les auteurs de l’EIP devraient continuer à travailler sur des propositions qui pourraient être incluses dans de futurs hard forks. Il n’est utilisé que pour les modifications et les mises à niveau de code axées sur EL. 「[CFI] plus élevé que les idées aléatoires de personnes aléatoires, mais avant qu’elles ne soient acceptées dans le fork », a déclaré Beiko.
Dans le passé, l’étiquetage des IFC n’a fait que peu ou pas d’efforts pour indiquer quels EIP de la LE seront mis en œuvre dans le cadre de la mise à niveau, ou quand. Il a été appliqué à un large éventail d’EIP avec différents degrés de préparation du code et de soutien de la part des équipes clientes. Dans le cas de la proposition de format d’objet EVM (EOF), les développeurs utilisent cette balise pour indiquer leur engagement à mettre en œuvre EOF dans la prochaine mise à niveau à venir, Cancun/Deneb. Cependant, l’EOF, ainsi que plusieurs autres propositions qui sont également signalées comme CFI, ont été rejetées par Cancun/Deneb, et il n’est pas clair quel est le statut de ces EIP marqués comme CFI dans la prochaine mise à niveau Prague/Electra.
Beiko a déclaré que si cet état n’aide pas, les développeurs devraient le supprimer, mais s’ils ont l’intention de le conserver, les développeurs CL devraient également utiliser la même étiquette sur les changements de code qu’ils envisagent d’implémenter dans les mises à niveau CL. Il n’est pas clair dans quelle mesure le processus d’examen du PIE du CL reflète le processus d’examen du PIE du CL et s’il devrait évoluer de la même manière à l’avenir. En règle générale, les modifications de code proposées à la spécification CL sont discutées lors de la conférence téléphonique de l’ACDC, tandis que les EIP proposés à la spécification EL sont discutés lors de la conférence téléphonique de l’ACDE.
Danno Ferrin, de Swirlds Labs, a également eu l’idée de créer un champ réservé pour tous les EIP, qu’ils soient liés à CL ou à EL, qui indique leur statut au cours du processus d’examen, y compris le statut de la FCI. Lors de cet appel, il n’y a pas eu de décision claire sur le sujet du statut EIP et de l’étiquetage CFI.