Ethereum suspend le fork Hoodi de Glamsterdam : ce que les auditeurs ont découvert

Les développeurs d'Ethereum ont mis en attente le fork du testnet Hoodi de Glamsterdam pendant qu'ils examinent les conclusions sur le comportement des applications lorsqu'une transaction manque de gaz. La mise à niveau modifie la façon dont le réseau facture certaines opérations qui touchent ou étendent son état, et les auditeurs ont constaté que même les contrats écrits avant la mise à niveau peuvent se comporter différemment sous les règles proposées.

Les développeurs d'Ethereum devaient forker Hoodi le 26 octobre. Ils ont reporté ce test, et le 6 novembre, le développeur de la Ethereum Foundation Marius van der Wijden a déclaré qu'il restait en attente pendant que les développeurs traitaient les problèmes identifiés dans l'examen du gaz.

La préoccupation se concentre sur un détail que la plupart des gens ne rencontrent que lorsqu'une transaction échoue. Les contrats peuvent appeler d'autres contrats et décider quoi faire si ces appels reviennent sans succès. Le code qui prend cette décision peut sembler exactement identique après une mise à niveau, mais emprunter un chemin différent parce que le réseau facture désormais différemment certaines parties de l'opération.

C'est pourquoi une mise à niveau visant la façon dont Ethereum comptabilise l'état est devenue une question pour les développeurs d'applications ainsi que pour les équipes qui écrivent les clients Ethereum. Les deux doivent savoir quelles anciennes hypothèses survivent au changement.

Ce que Glamsterdam change concernant le gaz

EIP-8037 modifie la façon dont le protocole comptabilise les opérations qui créent de l'état. L'état d'Ethereum comprend des enregistrements tels que le stockage des contrats. Un changement peut persister à travers les transactions, de sorte que son coût a des implications pour les nœuds qui maintiennent la chaîne après la fin de la transaction d'origine. La proposition sépare la comptabilisation de certaines créations d'état du gaz d'exécution ordinaire, avec un réservoir dans lequel on peut puiser pour les opérations éligibles.

EIP-8038 révise le prix des opérations qui accèdent à l'état. Les deux propositions affectent différentes parties d'un chemin d'exécution. Un contrat peut lire une valeur, effectuer un appel externe et écrire un résultat. Examiner uniquement le prix proposé de l'écriture finale manque l'effet des lectures et des appels antérieurs sur le budget disponible lorsque l'exécution l'atteint.

Une application familière peut donc produire un résultat différent même lorsqu'un utilisateur fournit les mêmes entrées de transaction. La question importante est de savoir quelles différences reflètent la révision tarifaire prévue et lesquelles exposent une hypothèse sur laquelle un client ou un contrat s'appuie.

Comment un appel échoué peut changer le résultat final

Considérez un contrat qui appelle un second contrat pour effectuer une étape dans une opération plus vaste. Si le second contrat échoue, l'appelant peut tout arrêter ou gérer l'échec et continuer. Un processeur par lots pourrait enregistrer un élément non réussi et passer au suivant. Une autre application pourrait s'attendre à ce que l'opération entière soit annulée si l'appel échoué épuise suffisamment de gaz.

L'analyse de ChainSecurity décrit comment la nouvelle comptabilité peut affecter cette distinction. Ethereum limite déjà la quantité de gaz qu'un appelant peut transmettre en vertu de la règle EIP-150. Environ un soixante-quatrième peut rester avec l'appelant dans le cas pertinent. Le problème est de savoir combien l'appelant a réellement à sa disposition une fois l'exécution revenue, et ce qu'il en coûte pour terminer les instructions sur ce chemin.

Supposons qu'une application traite un échec d'appel comme un résultat métier ordinaire. Si elle dispose de suffisamment de gaz pour terminer le gestionnaire d'échec, elle pourrait enregistrer un résultat ou poursuivre le reste de la transaction. Si elle l'épuise en cours de route, la transaction externe est annulée. Ces résultats laissent des enregistrements différents même si l'appel interne a échoué dans les deux cas.

L'auditeur a également examiné les vérifications basées sur gasleft(). Un contrat peut utiliser l'instruction pour comparer son budget d'exécution restant à un minimum codé en dur. Un seuil calibré sous un calendrier peut devenir un mauvais prédicteur sous un autre, en particulier lorsque le contrat rencontre des opérations d'état ou transmet du gaz à une autre adresse. Le contrat n'a aucun moyen automatique de réviser un nombre que son développeur a intégré lors de son déploiement.

Ce que les auditeurs doivent établir

La mise à jour de novembre de la Fondation décrit huit hypothèses en cours d'examen. Il y a au moins deux questions distinctes à tester. Les clients qui implémentent les nouvelles règles doivent parvenir au même résultat pour une transaction donnée. Les réviseurs d'applications doivent également identifier les cas où ce résultat partagé diffère de ce que les contrats existants attendent.

Un test pour la première question peut exécuter la même transaction sur plusieurs clients et comparer les résultats d'état et de gaz. Un test pour la seconde doit suivre la logique propre de l'application. Il importe de savoir si le contrat traite un rappel échoué comme un signal pour continuer, s'il enregistre un changement d'état avant l'appel et s'il peut distinguer un rejet métier d'un appel qui n'a jamais eu suffisamment de gaz.

Ces chemins peuvent être faciles à manquer dans un test de déploiement conventionnel. Un budget de transaction typique peut porter l'appel et son gestionnaire à travers les deux calendriers. Un budget délibérément serré peut exposer la différence. Les tests aux limites doivent donc inclure des appels échoués et des cas proches de la quantité de gaz requise pour entrer dans le gestionnaire d'échec ou le terminer.

Ce que Hoodi peut montrer

Glamsterdam avait déjà atteint le réseau de test Sepolia d'Ethereum, où les développeurs ont testé une limite de 200 millions de gaz. Hoodi offrirait aux développeurs un déploiement partagé supplémentaire pour exercer la mise à niveau révisée.

Un fork de réseau de test public donne aux équipes clients et aux opérateurs d'applications un environnement commun pour exécuter ces vérifications. Les opérateurs peuvent mettre à jour les clients selon un calendrier partagé, comparer leurs résultats et tester les outils par rapport aux règles du fork. Les équipes d'applications peuvent vérifier si la simulation de transaction et l'estimation du gaz tiennent compte des mêmes changements qu'ils observent pendant l'exécution.

Un fork Hoodi réussi donnerait aux développeurs des preuves sur les versions et les transactions qu'ils ont testées. La question à plus long terme est de savoir ce que font les applications représentatives aux limites de leurs budgets de gaz. Une nouvelle date de fork sera plus facile à évaluer avec un enregistrement des cas reproduits, de ce qui a changé en réponse et de la manière dont les équipes l'ont testé.

Le travail sur le gaz se déroule parallèlement à d'autres correctifs. Les développeurs d'Ethereum ont séparément révisé la spécification de dépôt des validateurs pendant que l'examen du gaz de Hoodi était en cours. Ces correctifs nécessitent leurs propres tests car ils affectent une partie différente du fork.

Pour l'instant, la dernière mise à jour des développeurs sur les risques liés au gaz donne une raison pour le report et indique que le travail sur Hegota se poursuit. Elle laisse le calendrier du prochain test de Glamsterdam à une décision ultérieure.

Comment les limites de gaz et les coûts d'état s'articulent

Une limite de gaz par bloc plus élevée donne à Ethereum plus de marge pour effectuer davantage de travail dans son système de comptabilité. Le prix attribué à une opération individuelle détermine quelle part de cette marge l'opération occupe. Une modification de la limite et une modification des prix peuvent donc affecter différentes parties d'une même transaction.

Certains travaux se terminent lorsque la transaction se termine. La création d'état est différente car les données peuvent persister, laissant aux opérateurs de nœuds quelque chose à stocker et à traiter plus tard. Un nouvel emplacement de stockage, un compte ou un contrat peut ajouter à cette charge même si l'application qui l'a créé reçoit peu de trafic par la suite.

L'EIP-8037 modifie la façon dont le coût de certaines créations d'état est comptabilisé. L'EIP-8038 révise le prix de l'accès à l'état, ce qui peut inclure des opérations impliquant des enregistrements qui existent déjà. Une transaction qui lit une valeur, appelle un autre contrat et crée une entrée de stockage peut rencontrer les deux changements au cours d'une seule exécution.

Une limite de bloc plus élevée seule ne dit pas si cette séquence coûtera plus ou moins. Elle décrit la marge disponible pour le bloc dans son ensemble. Le chemin de la transaction et le prix de chaque opération déterminent si elle peut tenir dans le gaz fourni par l'expéditeur.

Cette distinction était déjà pertinente lorsque Sepolia a commencé à tester Glamsterdam avec une limite de 200 millions de gaz. Le test a montré ce que les développeurs exécutaient sur ce réseau. La suspension sur Hoodi concerne la question de savoir si les règles sont prêtes pour le prochain testnet, y compris le comportement des applications qui reposent sur des hypothèses de gaz antérieures.

Les huit hypothèses à l'examen

Le dépôt d'audit de la Fondation Ethereum regroupe ses exemples par modifications des prix des opérations et modifications de la façon dont le gaz est suivi. Les chiffres du dépôt proviennent d'une version épinglée de la spécification proposée et peuvent changer si les propositions sont révisées.

Le premier groupe de préoccupations concerne les allocations fixes et le coût d'achèvement du travail après un appel. Les développeurs peuvent avoir fixé une limite de gaz pour une opération qui coûte désormais plus cher. Une réserve destinée à payer une écriture finale peut ne plus être suffisante. Dans un autre cas, la petite fraction retenue par un appelant peut suffire à achever un chemin d'échec que l'application s'attendait auparavant à voir se rétablir.

Les changements de comptabilité introduisent d'autres possibilités. Si un réservoir séparé peut encore financer une création d'état éligible, un appelant peut écrire un enregistrement après un appel échoué même lorsque son budget d'exécution ordinaire est serré. Le résultat final de l'appelant peut alors dépendre des opérations qui utilisent ce budget séparé.

La libération d'un emplacement créé plus tôt dans la même transaction peut restituer immédiatement une partie du gaz d'état dans la spécification examinée. Un appel qui se rétablit peut également restituer du gaz d'état. Le code écrit en supposant que tout le gaz consommé avant un rétablissement est perdu peut donc mal interpréter ce qui s'est passé.

Une paire de mesures de gasleft() peut de même donner une vue incomplète du coût du travail. Un contrat qui utilise la différence pour facturer quelqu'un ou calculer un remboursement repose sur des hypothèses quant à l'évolution du gaz entre les deux lectures. Les frais prélevés sur un pool séparé et le gaz d'état restitué pendant l'exécution peuvent modifier cette relation.

Le huitième cas concerne l'EIP-7702, qui permet à un compte d'autoriser une délégation vers du code de contrat. Une transaction peut être incluse même lorsqu'une autorisation qu'elle contient n'a pas pris effet faute de gaz suffisant. Un portefeuille ou un service qui utilise la seule inclusion de la transaction pour en déduire que la délégation a fonctionné pourrait traiter une action incomplète comme terminée.

Le dépôt indique que de nombreux constats reçus par ses auteurs concernaient des montants fixes ou des réserves. Il demande aux développeurs et aux auditeurs de tester leurs applications par rapport aux exemples et de signaler les problèmes. L'inventaire identifie des schémas qui nécessitent un examen. Il n'implique pas que chaque application utilisant l'un de ces schémas produira une perte.

Comment un appel échoué peut tout de même laisser une transaction réussie

Une transaction Ethereum peut contenir plusieurs appels. Un contrat peut demander à un autre contrat d'effectuer une étape, puis décider comment réagir au résultat. Un appel interne échoué et une transaction échouée sont des issues distinctes.

Un processeur de lots fournit un exemple utile. Si un élément échoue, le processeur peut enregistrer cet échec et passer à l'élément suivant. S'il manque de gaz avant de pouvoir enregistrer le résultat, la transaction externe peut être annulée et défaire les modifications antérieures. Le même échec interne laisse donc un état final différent selon ce que l'appelant peut faire ensuite.

Une autre application pourrait traiter un appel échoué comme une raison de changer qui peut soumettre une demande ou si elle est autorisée à être retentée. Si l'appelant peut achever un chemin que l'application s'attendait à voir annulé, l'état résultant peut persister. La conséquence de sécurité dépend de ce que le chemin achevé enregistre réellement.

Un acteur peut être en mesure de choisir la quantité de gaz qu'une transaction fournit. Si cette personne peut laisser suffisamment de gaz pour que le contrat externe entre dans un chemin, mais trop peu pour que l'appel interne se termine, l'échec peut être induit par le budget de la transaction. Un contrat qui agit sur l'échec doit distinguer ce cas d'un appel qui a atteint le destinataire et a échoué légitimement.

La limite de transfert de l'EIP-150 en est un aspect. Un appelant qui transfère autant de gaz que permis en conserve environ un soixante-quatrième selon la règle applicable. Le montant conservé doit encore payer les instructions qui suivent. La réussite de ces instructions dépend du calendrier et de la comptabilité qui leur est appliquée.

Un contrat peut être vulnérable à une plage étroite de budgets. Donnez suffisamment de gaz à l'appel interne et il fonctionne normalement. Donnez trop peu de gaz à l'ensemble de la transaction et le chemin externe est annulé. L'intervalle problématique est celui où l'appel interne échoue alors que l'appelant dispose encore de suffisamment de gaz pour exécuter une action que le développeur n'avait pas prévue pour cet échec.

Pourquoi changer un nombre de gaz fixe peut ne pas résoudre le problème

Un seuil codé en dur peut offrir à un contrat un moyen simple de vérifier qu'il dispose de suffisamment de gaz avant d'effectuer un appel. Le développeur a peut-être testé le seuil avec des transactions courantes et laissé une marge pour le travail qui suit. Le nombre devient une dépendance au calendrier selon lequel il a été choisi.

Une opération peut aussi coûter des montants différents selon que l'application met à jour un enregistrement existant ou en crée un. Un transfert vers quelqu'un qui possède déjà un solde peut emprunter un chemin de stockage différent d'un transfert qui crée un premier solde. Un test qui ne couvre que les destinataires récurrents peut manquer le chemin plus coûteux.

Le point où le contrat mesure le gaz importe. Une lecture immédiatement avant l'appel diffère d'une lecture après plusieurs accès à l'état et l'appel lui-même. Un contrat qui déduit la raison de l'échec à partir de cette dernière lecture suppose qu'il comprend ce qui a pu être facturé ou renvoyé entre-temps.

Changer une allocation peut avoir ses propres conséquences. Cela peut permettre à un chemin qui échouait auparavant de s'achever, et cela peut aussi donner au destinataire suffisamment de gaz pour effectuer un travail qu'il ne pouvait pas effectuer avec l'ancienne allocation. Le développeur doit savoir ce que l'allocation était censée empêcher avant de l'ajuster.

Certains contrats peuvent être modifiés par un processus de gouvernance ou administratif. D'autres sont immuables ou dépendent de composants qui ne peuvent pas être modifiés sur place. Même lorsqu'un contrat peut être révisé, les services qui estiment, parrainent ou relaient ses transactions peuvent aussi devoir mettre à jour leurs propres hypothèses.

Ce qu'une reproduction convaincante doit montrer

Un test peut commencer avec la même transaction, le même état et la même limite de gaz selon les anciennes règles et les règles proposées. Une comparaison devrait identifier quel appel renvoie un échec, ce que l'appelant fait ensuite et si la transaction enregistre des modifications qui ne persistaient pas auparavant.

Tester des budgets juste au-dessus et en dessous du seuil aide à montrer si l'effet occupe une plage étroite. Cela peut aussi identifier où l'exécution diverge. Une vérification précoce du solde, le montant transféré au destinataire et une écriture dans le gestionnaire d'échec sont différents points auxquels un changement peut se manifester.

Le réviseur doit alors se demander qui peut atteindre ce chemin. Un changement reproduit dans un contrat de test établit une différence d'exécution. Une application réelle peut exiger une autorisation, vérifier une condition distincte ou rendre l'opération concernée réessayable. Ces détails déterminent si quelqu'un peut forcer une issue non souhaitée.

Il existe également un test distinct pour les équipes clientes. Tous les clients d'exécution devraient atteindre le même résultat pour une transaction sous la même configuration de fork. Un désaccord entre clients est un problème différent de celui où tous les clients produisent systématiquement un résultat qu'une application n'avait pas anticipé.

Une suite de tests a besoin de chemins réussis autant que d'échecs. Forcer chaque appel échoué à faire un revert pourrait empêcher un changement d'état indésirable mais aussi supprimer une capacité légitime d'achever le reste d'un lot. Le comportement applicatif attendu détermine ce qu'un correctif doit préserver.

Une bonne reproduction devrait rendre l'état final facile à inspecter. Si un enregistrement d'échec subsiste après une exécution et disparaît après une autre, le test peut montrer la différence exacte plutôt que de s'appuyer sur un rapport général sur la consommation de gas. Cela facilite l'évaluation à la fois du risque et d'une modification proposée.

Ce que les testnets publics apportent après une reproduction locale

Un développeur peut tester un cas limite sur un fork local ou dans un environnement client contrôlé. Un testnet public permet ensuite à plusieurs opérateurs d'exécuter la même mise à niveau et de comparer son comportement dans des conditions partagées. Il donne aussi aux équipes de portefeuilles et d'infrastructure un endroit où tester leur propre logiciel face aux règles actives.

Sepolia et Hoodi servent des étapes différentes dans ce processus. L'activation de Sepolia a montré que les développeurs pouvaient exécuter le code prévu sur ce réseau et examiner son fonctionnement sous la limite de gas configurée. Hoodi leur offre un déploiement supplémentaire après avoir traité les constats devenus importants lors de la revue.

Les applications, le trafic et l'état historique sur un testnet diffèrent du mainnet. Un fork fluide peut fournir des preuves sur l'accord entre clients et les transactions courantes sans exercer chaque modèle de contrat sur lequel les utilisateurs s'appuient. Une reproduction ciblée fournit des preuves sur un cas limite qui peut être absent du trafic ordinaire du testnet.

Les instructions de mise à niveau font aussi partie du test. Un opérateur a besoin d'une version qui implémente la configuration prévue et d'un point d'activation précis. Une application doit savoir quand ses simulations doivent commencer à utiliser les règles révisées. Une nouvelle date est utile en complément de ces détails.

Le report d'octobre et le rapport de statut de novembre décrivent la même suspension à des moments différents. Le premier a retiré la date Hoodi planifiée. Le second a expliqué que les problèmes devaient encore être résolus. Le prochain avis de déploiement peut montrer quels changements sont prêts à être testés par les opérateurs.

Comment les portefeuilles peuvent signaler un succès alors qu'une action échoue

Les portefeuilles estiment couramment le gas avant de demander à un utilisateur de signer. L'estimation dépend de l'état et des règles que le nœud applique dans sa simulation. Un service utilisant une configuration de fork plus ancienne peut donner une estimation qui ne convient plus à une transaction que la chaîne actuelle exécute.

Une transaction qui fait un revert peut tout de même coûter du gas à l'expéditeur. Une transaction externe qui se termine après avoir intercepté un échec interne peut être plus difficile à interpréter. La chaîne peut enregistrer la transaction globale comme réussie alors qu'une action en son sein ne s'est pas produite. Le portefeuille peut avoir besoin des événements ou de l'état de l'application pour expliquer la différence à l'utilisateur.

Les relayers et les sponsors de transactions font face à un problème connexe. Ils peuvent choisir le budget ou payer les coûts d'une transaction que quelqu'un d'autre demande. Si le budget ne couvre plus le chemin prévu, le sponsor peut payer pour une exécution qui ne parvient pas à réaliser l'action demandée.

Les indexeurs peuvent voir l'effet après l'exécution. Un chemin d'échec qui s'achève désormais peut produire des logs ou des changements d'état que le système en aval ne voyait pas auparavant. L'indexeur suit toujours l'état réel de la chaîne. Une application qui s'appuie sur l'indexeur peut devoir changer sa façon d'interpréter l'enregistrement résultant.

Un test de bout en bout peut comparer l'estimation d'un portefeuille, le budget soumis par un relayer, le résultat d'exécution du client et l'explication de l'interface. Chaque étape peut réussir individuellement alors que l'utilisateur reçoit encore un compte rendu trompeur des actions qui ont pris effet. La distinction importe surtout là où l'application traite un résultat comme définitif.

Ce qui résoudrait la suspension de Hoodi

La Fondation demande aux équipes applicatives d'identifier les hypothèses qu'elles utilisent et de fournir des cas que les développeurs peuvent reproduire. Certains problèmes peuvent être traités par des changements dans les règles de gas proposées. D'autres peuvent nécessiter qu'une application ou un fournisseur d'infrastructure révise sa façon de gérer le nouveau comportement.

Si les spécifications changent, le test pertinent consiste à vérifier si un cas qui divergeait auparavant atteint désormais le résultat attendu. Si les développeurs conservent un changement de comportement, les équipes applicatives ont besoin de suffisamment de détails pour déterminer si leur logiciel s'appuie sur le résultat précédent. Les deux issues dépendent de la description de l'appel concerné et de ce qui persiste après celui-ci.

Une spécification révisée doit également atteindre les builds clients que les opérateurs exécutent. Un build qui prenait en charge une configuration Glamsterdam antérieure peut ne pas contenir les modifications ultérieures. Les numéros de version dans un nouvel avis Hoodi identifieraient quelles versions peuvent être testées ensemble.

La mise à jour de novembre de la Fondation indique que les travaux sur Hegota se poursuivent en parallèle. Cela signifie que la suspension du fork antérieur ne rend pas compte de toutes les décisions de développement concernant le suivant. Pour Glamsterdam, le prochain jalon pertinent est un calendrier Hoodi révisé avec une configuration que les développeurs sont prêts à exécuter publiquement.

Un fork réussi donnerait aux équipes un enregistrement partagé à examiner avant une décision sur le mainnet. Les cas qui ont motivé le retard restent les tests les plus clairs pour déterminer si les règles révisées sont prêtes. Ces tests doivent montrer ce qui se passe lorsqu'un appel échoue près de sa limite de gaz et que la transaction externe a encore du travail à accomplir.

Ce que les chiffres de gaz proposés montrent sur les différents chemins

Le dépôt de la Fondation donne un exemple concret de la différence entre créer un état et le mettre à jour. Selon sa spécification Glamsterdam épinglée, une écriture à froid qui crée un nouvel emplacement est répartie entre les coûts d'exécution et une charge d'état sensiblement plus importante. Une écriture dans un emplacement existant est également repricée, mais suit un calcul différent.

La différence peut concerner deux utilisateurs effectuant ce qui semble être la même demande applicative. Un utilisateur peut avoir déjà utilisé le service, de sorte que le contrat met à jour une entrée existante. Un autre peut avoir besoin d'un nouvel enregistrement. Une allocation de gaz qui fonctionne pour le premier utilisateur peut échouer pour le second.

Le dépôt indique également qu'un réservoir séparé n'est disponible qu'au-dessus d'une limite de gaz de transaction spécifiée dans la configuration testée. Dans les transactions plus petites, les coûts d'état proviennent plutôt du budget ordinaire. Ce seuil rend important de tester plusieurs budgets plutôt que de supposer que le réservoir se comporte de la même manière pour chaque appel.

Le code qui lit le gaz restant ne peut donc observer qu'une partie des ressources de la transaction dans certains cas. Les données qu'il lit restent significatives pour le budget que l'instruction expose. Ce qui change, c'est l'inférence que l'application peut tirer sur le total des ressources consommées ou encore disponibles.

Les exemples de gaz sont liés à la configuration proposée. Ils ne donnent pas un multiplicateur unique qui peut être appliqué aux estimations existantes d'un portefeuille. Une première écriture de stockage, un appel utilisant une allocation fixe et une délégation échouée nécessitent chacun une vérification séparée car ils rencontrent différentes parties des règles.

C'est aussi pourquoi une date Hoodi révisée serait plus utile avec la révision de la spécification et la liste des cas couverts par la version. Ces détails permettraient aux équipes de relancer des tests correspondant à leurs applications avant de tirer des conclusions de la stabilité globale du testnet.

Points à surveiller

• Calendrier de Hoodi : Une date de fork révisée devrait identifier les versions de clients et la configuration de fork que les opérateurs sont censés exécuter.
• Accord entre clients : Les tests inter-clients peuvent montrer si les clients d'exécution atteignent le même état et les mêmes résultats de gaz autour des nouvelles limites.
• Comportement des contrats : Les reproductions devraient montrer quand un appel externe échoué laisse à l'appelant suffisamment de gaz pour terminer et ce que la transaction externe enregistre.
• Révisions des propositions : Les modifications apportées à l'EIP-8037 ou à l'EIP-8038 aideront à montrer quels constats de revue ont nécessité un changement de protocole.
• Outillage applicatif : Les résultats de simulation et d'estimation de gaz peuvent montrer si les portefeuilles et les fournisseurs d'infrastructure reflètent correctement les règles du fork.

FAQ