Spécification de la couche d’exécution Ethereum | Blog de la Fondation Ethereum

Lecture 7 minutes

tl;dr

  • EELS est une implémentation de référence de couche d’exécution en Python.
  • Il est à jour avec le réseau principal.
  • Il remplit les tests et réussit ceux existants.
  • Vous trouverez ci-dessous un exemple d’EIP implémenté dans EELS.

Introduction

Après plus d’un an de développement, nous sommes heureux de présenter publiquement le Spécification de la couche d’exécution Ethereum (affectueusement connu sous le nom d’EELS.) EELS est une implémentation de référence Python des composants principaux d’un client d’exécution Ethereum axée sur la lisibilité et la clarté. Destiné à succéder spirituellement au Papier jaune c’est plus convivial pour les programmeurs et à jour avec les forks post-fusion, EELS peut remplir et exécuter des tests d’état, suivre le réseau principal1et constitue un endroit idéal pour prototyper de nouveaux EIP.

EELS fournit des instantanés complets du protocole à chaque fork, y compris les prochains, ce qui le rend beaucoup plus facile à suivre que EIP (qui ne proposent que des modifications) et les clients de production (qui mélangent souvent plusieurs forks dans le même chemin de code.)

Histoire

À partir de 2021, en tant que projet de l’équipe Quilt de ConsenSys et de la Fondation Ethereum, le spécification eth1.0 (comme on l’appelait à l’époque) a été inspiré par la pure frustration de devoir déchiffrer la notation énigmatique du Livre Jaune (Figure 1) pour comprendre le comportement spécifique d’une instruction EVM.

Capture d'écran des formules 2, 3 et 4 du Livre Jaune
Figure 1. runes mystérieuses décrivant la base du paradigme de la blockchain

S’appuyer sur le succès Spécification de la couche de consensusnous avons décidé de créer une spécification exécutable similaire pour la couche d’exécution.

Présent

Aujourd’hui, l’EELS est un consommable référentiel Python traditionnel et comme documentation rendue. C’est encore un peu approximatif sur les bords et ne fournit pas beaucoup d’annotations ou d’explications en anglais sur ce que font les différentes pièces, mais celles-ci viendront avec le temps.

C’est juste Python

Espérons qu’une comparaison côte à côte du Livre jaune et du code équivalent d’EELS puisse montrer pourquoi EELS en est un complément précieux :

Opcode inférieur à (LT)

Figure 2. Moins que (LT) Instruction EVM du Livre Jaune

def less_than(evm: Evm) -> None:
    # STACK
    left = pop(evm.stack)
    right = pop(evm.stack)

    # GAS
    charge_gas(evm, GAS_VERY_LOW)

    # OPERATION
    result = U256(left < right)

    push(evm.stack, result)

    # PROGRAM COUNTER
    evm.pc += 1

Figure 3. Moins que (LT) Instruction EVM de l’EELS

Alors que Figure 2 pourrait être digeste pour les universitaires, figure 3 est incontestablement plus naturel pour les programmeurs.

Voici une vidéo procédure pas à pas pour l’ajout d’une instruction EVM simple si c’est votre genre de chose.

Tests d’écriture

Il convient de le répéter : EELS n’est qu’un Python ordinaire. Elle peut être testée comme n’importe quelle autre bibliothèque Python ! En plus de l’ensemble ethereum/tests suite, nous avons également une sélection de test py essais.

Avec un peu d’aide de tests de spécifications d’exécutiontous les tests écrits pour EELS peuvent également être appliqués aux clients de production !2

Afficher les différences

Avoir des instantanés à chaque fork est idéal pour un développeur de contrats intelligents qui vient voir les détails du fonctionnement d’une instruction EVM, mais n’est pas très utile pour les développeurs clients eux-mêmes. Pour eux, EELS peut afficher les différences entre les fourches :

Capture d'écran des différences dans la fonction apply_fork entre homestead et le fork DAO

Graphique 4. une différence entre homestead et le fork DAO

Un exemple d’EIP

EIP-6780 est le premier EIP à obtenir une implémentation EELS fourni par l’auteur, Guillaume Ballet! Nous allons jeter un coup d’oeil.

Capture d'écran de la section de spécifications de l'EIP-6780

Graphique 5. Section de spécifications de l’EIP-6768

Tout d’abord, nous introduisons un contrats_créés variable à l’EVM avec une portée au niveau de la transaction :

 @dataclass
 class Environment:
     caller: Address
     block_hashes: List[Hash32]
     origin: Address
     coinbase: Address
     number: Uint
     base_fee_per_gas: Uint
     gas_limit: Uint
     gas_price: Uint
     time: U256
     prev_randao: Bytes32
     state: State
     chain_id: U64
+    created_contracts: Set[Address]

Deuxièmement, nous notons quels contrats ont été créés dans chaque transaction :

+    evm.env.created_contracts.add(contract_address)

Enfin, nous modifions auto-destruction donc cela ne fonctionne que pour les contrats notés dans contrats_créés:

-    # register account for deletion
-    evm.accounts_to_delete.add(originator)
-
+    # Only continue if the contract has been created in the same tx
+    if originator in evm.env.created_contracts:
+
+        # register account for deletion
+        evm.accounts_to_delete.add(originator)
+

Avenir

Nous voulons que l’EELS devienne le moyen par défaut de spécifier les Core EIP, le premier endroit où les auteurs d’EIP se rendent pour prototyper leurs propositions et la meilleure référence possible sur le fonctionnement d’Ethereum.

Si vous souhaitez contribuer ou prototyper votre EIP, rejoignez-nous sur le #Caractéristiques chaîne ou récupérez un numéro de notre dépôt.

Source https://blog.ethereum.org/en/2023/08/29/eel-spec

Crypto Week

Avertissement : Crypto Week ne fournit pas de conseils financiers de quelque manière que ce soit. Nous ne vous recommandons pas d'investir de l'argent dans une crypto-monnaie ou un actif financier sans avoir effectué des recherches approfondies. Nous ne sommes pas responsables de vos décisions financières de quelque manière que ce soit.

Derniers articles de Featured Posts