Comment la fusion affecte la couche d’application d’Ethereum

Remarque : ce message a été mis à jour en mars 2022 pour refléter les dernières modifications apportées aux spécifications.
Celles-ci incluent le changement de nom des spécifications de la couche consensus en « Bellatrix », le changement de nom du ALÉATOIRE code d’opération à PREVRANDO et les changements de spécification JSON RPC.

La transition d’Ethereum vers la preuve d’enjeu – The Merge – est proche : les devnets sont mis en place, les spécifications sont en cours de finalisation et la sensibilisation de la communauté a commencé sérieusement. La fusion est conçue pour avoir un impact minimal sur le fonctionnement d’Ethereum pour les utilisateurs finaux, les contrats intelligents et les dapps. Cela dit, il y a quelques changements mineurs qui méritent d’être soulignés. Avant de nous y plonger, voici quelques liens pour fournir un contexte sur l’architecture globale de Merge :

Le reste de cet article supposera que le lecteur est familier avec ce qui précède. Pour ceux qui souhaitent creuser encore plus profondément, les spécifications complètes de The Merge sont disponibles ici :

Structure de bloc

Après la fusion, les blocs de preuve de travail n’existeront plus sur le réseau. Au lieu de cela, l’ancien contenu des blocs de preuve de travail devient un composant des blocs créés sur la chaîne Beacon. Vous pouvez alors considérer la chaîne Beacon comme devenant la nouvelle couche de consensus de preuve d’enjeu d’Ethereum, remplaçant la précédente couche de consensus de preuve de travail. Les blocs de chaîne Beacon contiendront Charges utiles d’exécution, qui sont l’équivalent post-fusion des blocs sur la chaîne de preuve de travail actuelle. L’image ci-dessous montre cette relation :

Pour les utilisateurs finaux et les développeurs d’applications, ces Charges utiles d’exécution sont là où les interactions avec Ethereum se produisent. Les transactions sur cette couche seront toujours traitées par les clients de la couche d’exécution (Besu, Erigon, Geth, Nethermind, etc.). Heureusement, en raison de la stabilité de la couche d’exécution, The Merge n’introduit que des changements minimes avec rupture.

Champs miniers et blocs d’Ommer

Après la fusion, plusieurs champs précédemment contenus dans les en-têtes de bloc de preuve de travail deviennent inutilisés car ils ne sont pas pertinents pour la preuve d’enjeu. Afin de minimiser les perturbations de l’outillage et de l’infrastructure, ces champs sont définis sur 0, ou l’équivalent de leur structure de données, plutôt que d’être entièrement supprimés de la structure de données. Les modifications complètes apportées aux champs de bloc peuvent être trouvées dans EIP-3675.

Étant donné que la preuve d’enjeu ne produit pas naturellement des ommers (aka oncle blocks) comme une preuve de travail, la liste de ceux-ci dans chaque bloc (ommers) sera vide, et le hachage de cette liste (ommersHash) deviendra le hachage encodé RLP d’une liste vide. De même, parce que difficulté et nonce sont des fonctionnalités de la preuve de travail, celles-ci seront définies sur 0tout en respectant leurs valeurs de taille d’octet.

mixHash, un autre champ lié au minage, ne sera pas défini sur 0 mais contiendra à la place la valeur RANDAO de la chaîne de balises. Plus à ce sujet ci-dessous.

BLOCHASH & DIFFICULTÉ changements d’opcodes

Après la fusion, le BLOCHASH L’opcode sera toujours utilisable, mais étant donné qu’il ne sera plus falsifié par le processus de hachage de preuve de travail, le caractère pseudo-aléatoire fourni par cet opcode sera beaucoup plus faible.

De manière connexe, le DIFFICULTÉ code opération (0x44) sera mis à jour et renommé en PREVRANDAO. Après la fusion, il renverra la sortie de la balise aléatoire fournie par la chaîne de balises. Cet opcode sera donc une source d’aléa plus forte, bien que toujours biaisée, pour les développeurs d’applications à utiliser que BLOCHASH.

La valeur exposée par PREVRANDAO seront stockés dans le Charge utile d’exécution où mixHash, une valeur associée au calcul de la preuve de travail, a été stockée. La charge utile mixHash le champ sera également renommé prevRandao.

Voici une illustration de la façon dont le DIFFICULTÉ & PREVRANDAO les opcodes fonctionnent avant et après la fusion :

Avant la fusion, nous voyons le 0x44 l’opcode renvoie le difficulté champ dans l’en-tête du bloc. Post-merge, l’opcode, renommé en PREVRANDAOpointe vers le champ d’en-tête qui contenait auparavant mixHash et stocke maintenant le prevRandao valeur de l’état de la chaîne de balises.

Ce changement, formalisé dans EIP-4399, fournit également aux applications en chaîne un moyen d’évaluer si la fusion a eu lieu. De l’EIP :

De plus, les modifications proposées par cet EIP permettent aux contrats intelligents de déterminer si la mise à niveau vers le PoS a déjà eu lieu. Cela peut être fait en analysant la valeur de retour du DIFFICULTÉ opcode. Une valeur supérieure à 2**64 indique que la transaction est en cours d’exécution dans le bloc PoS.

Temps de blocage

La fusion aura un impact sur le temps de blocage moyen sur Ethereum. Actuellement sous preuve de travail, les blocs arrivent en moyenne toutes les ~ 13 secondes avec une bonne quantité de variance dans les temps de bloc réels. Sous preuve de participation, les blocs arrivent exactement toutes les 12 secondes, sauf lorsqu’un créneau est manqué, soit parce qu’un validateur est hors ligne, soit parce qu’il ne soumet pas un bloc à temps. En pratique, cela se produit actuellement dans <1 % des emplacements.

Cela implique une réduction d’environ 1 seconde des temps de blocage moyens sur le réseau. Les contrats intelligents qui supposent un temps de bloc moyen particulier dans leurs calculs devront en tenir compte.

Tête de sécurité et blocs finalisés

Sous preuve de travail, il y a toujours un potentiel de réorganisation. Les applications attendent généralement que plusieurs blocs soient extraits au-dessus d’une nouvelle tête avant de la traiter comme peu susceptible d’être retirée de la chaîne canonique, ou « confirmée ». Après The Merge, nous avons plutôt les concepts de finalisé et tête sûre blocs. Ces blocs peuvent être utilisés de manière encore plus fiable que les blocs de preuve de travail « confirmés », mais nécessitent un changement de compréhension pour être utilisés correctement.

Un bloc finalisé est un bloc qui a été accepté comme canonique par > 2/3 des validateurs. Pour créer un bloc conflictuel, un attaquant devrait brûler au moins 1/3 de la mise totale. Au moment d’écrire ces lignes, cela représente plus de 10 milliards de dollars (ou > 2,5 millions d’ETH) sur Ethereum.

UN tête sûre bloc est celui qui, dans des conditions de réseau normales, devrait être inclus dans la chaîne canonique. En supposant des retards de réseau inférieurs à 4 secondes, une majorité honnête de validateurs et aucune attaque sur la règle du choix de fourchette, le tête sûre ne sera jamais orphelin. Une présentation détaillant comment la hauteur de sécurité est calculée selon différents scénarios est disponible ici. En outre, les hypothèses et garanties de tête sûre sont formellement définis et analysés dans un article à venir.

Les API de couche d’exécution post-fusion (par exemple JSON RPC) exposeront le tête sûre utilisant un sûr étiquette. Dans des conditions de réseau normales, le tête sûre et la pointe réelle de la chaîne sera équivalente (avec une tête de sécurité ne traînant que de quelques secondes). Têtes sûres sera moins susceptible d’être réorganisé que la preuve de travail actuelle dernier blocs.

Les blocs finalisés seront également exposés via JSON RPC, via un nouveau finalisé drapeau. Celles-ci peuvent alors servir de substitut plus solide aux confirmations de preuve de travail. Le tableau ci-dessous résume ceci :

Remarque : la spécification JSON RPC est toujours en cours de développement. Il faut encore s’attendre à des changements de nommage.

Prochaines étapes

Nous espérons que cet article aidera les développeurs d’applications à se préparer à la transition tant attendue vers la preuve d’enjeu. Au cours des prochaines semaines, un testnet de longue durée sera mis à disposition pour être testé par la communauté au sens large. Il y a aussi un prochain Fusionner l’appel de la communauté pour les développeurs d’infrastructures, d’outils et d’applications pour poser des questions et entendre les dernières mises à jour techniques sur The Merge. A bientôt ??

---

Merci à Mikhail Kalinin d’avoir fourni le contenu principal de la section « Safe Head » et à Danny Ryan et Matt Garnett d’avoir révisé les brouillons de cet article.