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

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 de la preuve de travail devient un composant des blocs créés sur la chaîne Beacon. Vous pouvez alors considérer la chaîne de balises comme 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 de balise contiendront ExecutionPayloads, 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 ExecutionPayloads sont 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 de rupture minimes.

Mines et champs de blocs 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 de participation. 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.

Parce que la preuve d’enjeu ne produit pas naturellement des ommers (alias blocs d’oncle) 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 difficulty et nonce sont des caractéristiques de la preuve de travail, celles-ci seront définies sur 0, tout en respectant leurs valeurs de taille d’octet.

mixHash, un autre champ lié à l’exploitation minière, 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.

BLOCKHASH & DIFFICULTY modifications des codes d’opération

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

En relation, le DIFFICULTY code opération (0x44) sera mis à jour et renommé en RANDOM. 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éatoire plus forte, bien que toujours biaisée, que les développeurs d’applications utiliseront BLOCKHASH.

La valeur exposée par RANDOM sera stocké dans le ExecutionPayload 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é random.

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

Avant la fusion, nous voyons le 0x44 opcode renvoie le difficulty champ dans l’en-tête du bloc. Post-merge, l’opcode, renommé en RANDOM, pointe vers le champ d’en-tête qui contenait auparavant mixHash et stocke maintenant le random 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 de l’opcode DIFFICULTE. 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 assez grande variation dans les temps de bloc réels. Sous preuve de mise, 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’ils ne soumettent pas de bloc à temps. En pratique, cela se produit actuellement dans <1% des créneaux.

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 sûre 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 considérer 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.

UNE tête sûre est un bloc qui, dans des conditions de réseau normales, nous attend d’être inclus dans la chaîne canonique. En supposant des délais de réseau inférieurs à 4 secondes, une honnête majorité de validateurs et aucune attaque contre la règle du choix de la fourchette, le tête sûre ne sera jamais orphelin. Une présentation détaillant la façon dont la hauteur de sécurité est calculée selon divers scénarios est disponible ici. De plus, les hypothèses et garanties de tête sûre sont formellement définis et analysés dans un prochain document.

Les API de couche d’exécution post-fusion (par exemple JSON RPC) renverront le tête sûre par défaut lorsqu’on lui demande le latest bloquer. Dans des conditions de réseau normales, le tête sûre et la pointe réelle de la chaîne sera équivalente (avec la tête sûre ne traînant que de quelques secondes). Têtes sûres sera moins susceptible d’être réorganisé que la preuve de travail actuelle latest blocs. Pour exposer la pointe réelle de la chaîne de preuve de mise, un unsafe flag sera ajouté à JSON RPC.

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

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 également un prochain appel communautaire Merge 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. Rendez-vous là-bas

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