Cet article est compilé et organisé par BlockWeeks
Merge est la transition d'Ethereum du consensus de preuve de travail (PoW) vers la preuve d'enjeu (PoS), et aussi le changement de code le plus complexe et le plus radical de l'histoire d'Ethereum. Son processus d'activation est différent de tout hard fork précédent : il se compose de trois étapes majeures et exige que les opérateurs de nœuds passent de l'exécution d'un seul client logiciel à l'exécution simultanée de deux clients. En tant que plus grande blockchain à usage général au monde par capitalisation boursière et valeur totale verrouillée, la valeur et la réputation en jeu dans la transition d'Ethereum sont énormes.
Ce que le Merge est censé résoudre : la fusion de deux chaînes
Actuellement, les transactions Ethereum sont finalisées via un protocole de consensus PoW appelé ethash. Fonctionnant en parallèle de cette chaîne PoW se trouve la Beacon Chain — une blockchain indépendante qui exécute de manière autonome le nouveau protocole de consensus PoS d'Ethereum, Gasper, depuis décembre 2020.
L'objectif du Merge est de fusionner les deux chaînes : faire en sorte que la blockchain existante d'Ethereum repose entièrement sur la Beacon Chain pour produire le consensus réseau, et abandonner complètement la preuve de travail. L'Ethereum que nous connaissons aujourd'hui ne traitera plus les transactions via ethash, mais existera uniquement en tant que couche d'exécution (EL), pour que les applications décentralisées et les utilisateurs diffusent des transactions. L'Ethereum Virtual Machine (EVM), le moteur de calcul d'Ethereum, continuera de fonctionner normalement sur la couche d'exécution.
La Beacon Chain devient alors la couche de consensus (CL) d'Ethereum : les transactions de la couche d'exécution y sont reçues, traitées et finalisées. L'emballage des transactions de la couche d'exécution en blocs et leur finalisation via le protocole Gasper deviendra la responsabilité des validateurs de la Beacon Chain. Après le Merge, pour suivre la chaîne principale d'Ethereum, tous les validateurs et opérateurs de nœuds complets doivent exécuter simultanément deux clients logiciels — un client de couche d'exécution et un client de couche de consensus.
Première étape : le hard fork Bellatrix
Premièrement, la couche de consensus d'Ethereum exécute un hard fork appelé Bellatrix. Bellatrix introduit une nouvelle structure de bloc de la Beacon Chain au niveau de la couche de consensus pour accueillir les blocs portant des transactions de la couche d'exécution. Il intègre également un ensemble d'instructions afin que les nœuds de la couche de consensus ne commencent à insérer des transactions de la couche d'exécution dans les blocs beacon qu'une fois que la couche d'exécution atteint une « difficulté totale terminale » (TTD) spécifique. Tous les nœuds de la couche de consensus doivent être mis à niveau vers Bellatrix avant une hauteur de slot spécifiée (équivalente à la hauteur de bloc sur la chaîne PoW). Une fois Bellatrix terminé, les nœuds de la couche de consensus commencent à surveiller la TTD.
Conception clé : pourquoi utiliser la TTD plutôt que la hauteur de bloc
La difficulté totale terminale mesure la difficulté minière cumulée de la couche d'exécution d'Ethereum. Ici, la « difficulté » désigne la difficulté pour les mineurs d'ajouter un nouveau bloc à la blockchain, représentant le nombre de combinaisons que les mineurs doivent généralement essayer pour trouver le bon hash générant le bloc suivant. À mesure que la puissance de calcul (taux de hachage) fournie par les mineurs augmente, la difficulté augmente automatiquement. La TTD est la somme de la difficulté minière de tous les blocs de l'histoire d'Ethereum.
Historiquement, les activations de hard fork de la couche d'exécution ne reposaient jamais sur une TTD spécifique, mais plutôt sur une hauteur de bloc prédéfinie. Le Merge a abandonné cette approche en raison de la possibilité d'une attaque par « fork rapide » : un attaquant pourrait utiliser une minorité de puissance de hachage pour forker la couche d'exécution et miner jusqu'au numéro de bloc spécifié plus rapidement que la chaîne principale. Si cela se produisait, la couche de consensus pourrait par erreur finaliser le merge avec la chaîne minoritaire de l'attaquant plutôt qu'avec la chaîne principale. Par conséquent, les développeurs ont choisi d'utiliser la TTD comme seuil de déclenchement du Merge, car il est beaucoup plus difficile pour des acteurs malveillants de la manipuler.
Mais l'utilisation de la TTD comme seuil a aussi un coût : la TTD est une valeur extrêmement difficile à prédire, ce qui rend également la prédiction du moment d'activation du Merge après Bellatrix délicate et imprécise. Cette conséquence s'est manifestée lorsque les développeurs principaux ont tenté pour la première fois d'activer le Merge sur le testnet Ropsten — le paramètre TTD initial était inexact, ce qui a fait dévier le moment d'activation des attentes.
Étape deux et étape trois : Paris et le commutateur de la couche d'exécution
Lorsque la couche d'exécution atteint le seuil TTD, deux propositions de mise à niveau de la couche d'exécution sont déclenchées, dont l'une est l'EIP-4399 : elle modifie la manière dont l'aléatoire on-chain est généré, en ne s'appuyant plus sur la difficulté de minage pour générer des entiers aléatoires destinés aux dApps. Les deux EIP s'activent simultanément au moment où le TTD est atteint. En même temps, les nœuds de la couche de consensus qui attendaient et surveillaient cette valeur TTD commencent également à traiter les transactions provenant de la couche d'exécution à partir de ce moment-là.
Le rythme des versions clients et la communication avec les parties prenantes doivent être soulignés. Pour préparer le hard fork Bellatrix, la Fondation Ethereum devrait publier un article de blog plusieurs semaines à l'avance listant les versions clients correspondant aux mises à niveau Paris et Bellatrix, afin que les opérateurs de nœuds puissent les télécharger à l'avance. Ces versions initiales seront remplies avec une valeur TTD anormalement élevée à titre de valeur de remplacement. Étant donné que Bellatrix s'active à une hauteur de slot spécifique, la date et l'heure estimée de cette mise à niveau seront également communiquées aux parties concernées.
Une fois Bellatrix terminé, la nouvelle valeur TTD sera communiquée aux opérateurs de nœuds via un second article de blog. Cette fois, une mise à niveau complète des clients de la couche de consensus ou de la couche d'exécution n'est pas nécessaire ; au minimum, il suffit d'ajouter une ligne de code à chacun des deux types de clients pour remplacer manuellement la valeur TTD précédente. Des mises à niveau facultatives des clients peuvent également être proposées à ce moment-là, mais il s'agit d'une décision propre à chaque équipe client et en aucun cas d'une version obligatoire requise pour suivre la phase finale de la Fusion.
Après l'annonce de la valeur de remplacement du TTD, la phase d'attente de l'atteinte du nouveau seuil commence. Bien qu'il existe des estimations temporelles approximatives, la date et l'heure exactes de l'activation de Paris ne peuvent pas être connues précisément à l'avance.
Risques d'exécution qui ne peuvent être ignorés
1. Le vide opérationnel causé par un calendrier imprévisible
L'impossibilité de prédire précisément le TTD signifie que tous les services dépendant d'Ethereum ne peuvent pas verrouiller à l'avance l'heure exacte du « moment de la Fusion ». Pour les entreprises qui doivent suspendre ou geler les dépôts et les retraits, cela représente un véritable défi opérationnel.
2. La pression opérationnelle de l'architecture à double client
Après la Fusion, les opérateurs de nœuds doivent exécuter simultanément les clients de la couche d'exécution et de la couche de consensus, et toute mauvaise configuration ou incompatibilité de version de l'un ou l'autre côté pourrait entraîner un retard d'un nœud. Les répétitions préalables sur les réseaux de test (Sepolia, Goerli) deviennent donc cruciales.
3. Un changement fondamental dans la production de blocs et la logique de finalité
Après la Fusion, les blocs ne seront plus finalisés en unités de hauteur de bloc, mais en unités de slots et d'époques. Les validateurs traitent un slot toutes les 12 secondes, et 32 slots constituent une époque, soit une époque toutes les 6,4 minutes. Les transactions sur la Beacon Chain atteignent la finalité après 2 époques, soit environ 12,8 minutes. Pour les exchanges, les DEX et autres applications DeFi construits sur des hypothèses différentes concernant la finalité des transactions et la vitesse de confirmation, ces changements à venir doivent être anticipés et préparés à l'avance afin d'éviter des interruptions de service ou des exploitations.
Conclusion : faible probabilité, fort impact
La transition d'Ethereum de la PoW à la PoS est la mise à niveau de blockchain de couche 1 la plus suivie et la plus lourde de conséquences de l'histoire des cryptomonnaies ; jamais auparavant un réseau comparable en échelle et en importance à Ethereum n'avait subi un changement aussi radical. Parce que les développeurs ont investi d'énormes efforts de test et de préparation, la probabilité que les risques ci-dessus impactent gravement les utilisateurs et les dApps n'est pas élevée ; mais si l'un des scénarios décrits dans cet article se produisait, au point que le réseau doive annuler la mise à niveau au moyen d'un hard fork d'urgence, la valeur et la réputation d'Ethereum en tant que blockchain à usage général pourraient être endommagées.
Par conséquent, toutes les parties prenantes doivent être conscientes de ces risques et prendre des mesures pour atténuer l'impact des problèmes potentiels sur leur propre utilisation du réseau, par exemple en suspendant ou en gelant les dépôts et les retraits pendant les fenêtres critiques où des interruptions peuvent survenir. En même temps, les validateurs, les dApps et les fournisseurs de services doivent se préparer en participant aux répétitions d'activation ultérieures sur les réseaux de test Sepolia et Goerli, ce qui peut à la fois garantir que les opérateurs de nœuds maîtrisent les meilleures pratiques pour suivre la mise à niveau Merge et exposer les problèmes du processus avant l'activation du réseau principal. En outre, la vigilance de la Fondation Ethereum, des équipes clientes et des médias de confiance contre la désinformation liée à Merge pendant l'activation est particulièrement critique—y compris les valeurs TTD incorrectes, les versions clientes incorrectes, les attentes de synchronisation incorrectes et les conseils opérationnels incorrects—et ils doivent se coordonner rapidement pour informer clairement les parties concernées de ce qu'il faut préparer ensuite, jusqu'à ce que la mise à niveau Merge soit complètement terminée.
