Traduit de Anglais vers Français - www.onlinedoctranslator.

com

ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ

RÉVISION EIP-150

DR. GAVIN BOIS

FONDATEUR, ETHEREUM & ETHCORE
GAVIN@ETHCORE.IO

Abstrait.Le paradigme de la blockchain, lorsqu'il est associé à des transactions sécurisées par cryptographie, a démontré son utilité à travers un
certain nombre de projets, notamment Bitcoin. Chacun de ces projets peut être considéré comme une simple application sur une ressource de
calcul décentralisée, mais unique. Nous pouvons appeler ce paradigme une machine singleton transactionnelle avec état partagé.

Ethereum implémente ce paradigme de manière généralisée. En outre, il fournit une pluralité de telles ressources, chacune avec un état et un
code de fonctionnement distincts mais capables d'interagir avec d'autres via un cadre de transmission de messages. Nous discutons de sa
conception, des problèmes de mise en œuvre, des opportunités qu'il offre et des obstacles futurs que nous envisageons.

1.Introduction l'information fait souvent défaut et les vieux préjugés sont

Avec des connexions Internet omniprésentes dans la plupart des
endroits du monde, la transmission mondiale d'informations est
devenue incroyablement bon marché. Des mouvements ancrés dans
la technologie comme Bitcoin ont démontré, grâce à la puissance du
défaut, des mécanismes de consensus et du respect volontaire du
contrat social, qu'il est possible d'utiliser Internet pour créer un
système de transfert de valeur décentralisé, partagé à travers le
monde et pratiquement gratuit pour utiliser. Ce système peut être
considéré comme une version très spécialisée d'une machine d'état
cryptographiquement sécurisée et basée sur les transactions. Des
systèmes de suivi tels que Namecoin ont adapté cette "application
monétaire" originale de la technologie dans d'autres applications,
quoique plutôt simplistes.
Ethereum est un projet qui tente de construire la technologie
généralisée ; technologie sur laquelle tous les concepts de machines à
états basés sur les transactions peuvent être construits. De plus, il vise
à fournir au développeur final un système de bout en bout
étroitement intégré pour la construction de logiciels sur un paradigme
de calcul jusqu'ici inexploré dans le courant dominant : un cadre de
calcul de messagerie d'objets de confiance.
1.1.Facteurs de conduite.Les objectifs de ce projet sont
nombreux; l'un des principaux objectifs est de faciliter les
transactions entre des individus consentants qui, autrement,
n'auraient aucun moyen de se faire confiance. Cela peut être dû à
la séparation géographique, à la difficulté d'interface, ou peut-
être à l'incompatibilité, l'incompétence, la réticence, les dépenses,
l'incertitude, les inconvénients ou la corruption des systèmes
juridiques existants. En spécifiant un système de changement
d'état à travers un langage riche et sans ambiguïté, et en outre en
concevant un système tel que nous pouvons raisonnablement
nous attendre à ce qu'un accord soit ainsi appliqué de manière
autonome, nous pouvons fournir un moyen à cette fin.
Les transactions dans ce système proposé auraient plusieurs attributs
que l'on ne trouve pas souvent dans le monde réel. L'incorruptibilité du
jugement, souvent difficile à trouver, vient naturellement d'un interprète
algorithmique désintéressé. La transparence, ou être capable de voir
exactement comment un état ou un jugement est survenu à travers le
journal des transactions et les règles ou codes d'instruction, ne se produit
jamais parfaitement dans les systèmes basés sur l'homme puisque le
langage naturel est nécessairement vague,
1
difficiles à ébranler.
Dans l'ensemble, je souhaite fournir un système tel que les
utilisateurs puissent être assurés que, quels que soient les autres
individus, systèmes ou organisations avec lesquels ils interagissent, ils
peuvent le faire avec une confiance absolue dans les résultats
possibles et comment ces résultats pourraient se produire.
1.2.Précédent travail.Buterin [2013a] a proposé pour la première
fois le noyau de ce travail fin novembre 2013. Bien qu'elle ait
maintenant évolué à bien des égards, la fonctionnalité clé d'une
blockchain avec un langage Turing-complet et une capacité de
stockage inter-transaction effectivement illimitée reste
inchangée.
Dwork et Naor [1992] ont fourni les premiers travaux sur
l'utilisation d'une preuve cryptographique de dépenses de calcul
("preuve de travail") comme moyen de transmettre un signal de valeur
sur Internet. Le signal de valeur a été utilisé ici comme un mécanisme
de dissuasion du spam plutôt que comme n'importe quel type de
devise, mais a démontré de manière critique le potentiel d'un canal de
données de base pour transporter unsignal économique fort,
permettant à un récepteur de faire une affirmation physique sans
avoir à s'appuyer surconfiance. Back [2002] a produit plus tard un
système dans la même veine.
Le premier exemple d'utilisation de la preuve de travail
comme signal économique fort pour sécuriser une devise a été
celui de Vishnumurthy et al. [2003]. Dans ce cas, le jeton a été
utilisé pour contrôler le commerce de fichiers peer-to-peer,
garantissant que les «consommateurs» puissent effectuer des
micro-paiements aux «fournisseurs» pour leurs services. Le
modèle de sécurité offert par la preuve de travail a été complété
par des signatures numériques et un registre afin de garantir que
l'historique ne puisse pas être corrompu et que les acteurs
malveillants ne puissent pas usurper le paiement ou se plaindre
injustement de la prestation de services. Cinq ans plus tard,
Nakamoto [2008] a introduit un autre jeton de valeur sécurisé par
preuve de travail, un peu plus large. Les fruits de ce projet,
Bitcoin, sont devenus le premier grand livre de transactions
décentralisé mondial largement adopté.
D'autres projets construits sur le succès de Bitcoin ; les alt-
coins ont introduit de nombreuses autres devises en modifiant le
protocole. Certains des plus connus sont Litecoin et Primecoin,
discutés par Sprankel [2013]. D'autres projets ont cherché à
prendre le mécanisme de contenu de valeur de base du
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ
protocole et le réutiliser ; Aron [2012] évoque par exemple
le projet Namecoin qui vise à fournir un système
décentralisé de résolution de noms.
D'autres projets visent toujours à s'appuyer sur le réseau
Bitcoin lui-même, en tirant parti de la grande quantité de valeur
placée dans le système et de la grande quantité de calculs qui
entrent dans le mécanisme de consensus. Le projet Mastercoin,
proposé pour la première fois par Willett [2013], vise à construire
un protocole plus riche impliquant de nombreuses fonctionnalités
supplémentaires de haut niveau en plus du protocole Bitcoin
grâce à l'utilisation d'un certain nombre de parties auxiliaires du
protocole principal. Le projet Coloured Coins, proposé par
Rosenfeld [2012], adopte une stratégie similaire mais plus
simplifiée, embellissant les règles d'une transaction afin de briser
la fongibilité de la devise de base de Bitcoin et permettre la
création et le suivi de jetons grâce à un "chroma- portefeuille »-
logiciel compatible avec le protocole.
Un travail supplémentaire a été fait dans le domaine avec
l'abandon de la base de la décentralisation ; Ripple, discuté par
Boutellier et Heinzen [2014], a cherché à créer un système «
fédéré » pour l'échange de devises, créant ainsi un nouveau
système de compensation financière. Il a démontré que des gains
d'efficacité élevés peuvent être réalisés si la prémisse de la
décentralisation est rejetée.
Les premiers travaux sur les contrats intelligents ont été réalisés
par Szabo [1997] et Miller [1997]. Vers les années 1990, il est devenu
clair que l'application algorithmique des accords pourrait devenir une
force importante dans la coopération humaine. Bien qu'aucun
système spécifique n'ait été proposé pour mettre en œuvre un tel
système, il a été suggéré que l'avenir du droit serait fortement affecté
par de tels systèmes. Dans cette optique, Ethereum peut être
considéré comme une mise en œuvre générale d'un telcrypto-loi
système.
2.Le paradigme de la blockchain
Ethereum, pris dans son ensemble, peut être considéré comme
une machine à états basée sur les transactions : nous commençons
par un état de genèse et exécutons progressivement les transactions
pour le transformer en un état final. C'est cet état final que nous
acceptons comme la "version" canonique du monde d'Ethereum.
L'état peut inclure des informations telles que les soldes de comptes,
les réputations, les accords de confiance, les données relatives aux
informations du monde physique ; bref, tout ce qui peut actuellement
être représenté par un ordinateur est recevable. Les transactions
représentent ainsi un arc valide entre deux états ; la partie 'valide' est
importante - il existe beaucoup plus de changements d'état invalides
que de changements d'état valides. Les changements d'état non
valides peuvent, par exemple, être des choses telles que la réduction
d'un solde de compte sans une augmentation égale et opposée
ailleurs. Une transition d'état valide est une transition qui se produit
par le biais d'une transaction. Officiellement:
(1) σt+1≡Υ(σt, T)
où Υ est la fonction de transition d'état d'Ethereum. Dans
Ethereum, Υ, avecσsont considérablement plus puissants que
n'importe quel système comparable existant ; Υ permet aux
composants d'effectuer des calculs arbitraires, tandis queσ
permet aux composants de stocker un état arbitraire entre les
transactions.
Les transactions sont regroupées en blocs ; les blocs sont
enchaînés en utilisant un hachage cryptographique comme moyen de
référence. Les blocs fonctionnent comme un journal, enregistrant une
série de transactions avec le bloc précédent et un
RÉVISION EIP-150 2
identifiant de l'état final (mais ne stockez pas l'état final lui-même, ce
serait beaucoup trop volumineux). Ils ponctuent également la série de
transactions avec des incitations pour les nœuds à exploiter. Cette
incitation se déroule comme une fonction de transition d'état, ajoutant
de la valeur à un compte désigné.
L'exploitation minière est le processus consistant à consacrer des
efforts (travail) pour renforcer une série de transactions (un bloc) par
rapport à tout autre bloc concurrent potentiel. Elle est réalisée grâce à une
preuve cryptographiquement sécurisée. Ce schéma est connu sous le nom
de preuve de travail et est décrit en détail dans la section 11.5.
Formellement, nous nous étendons à :
(2) σt+1 ≡ Π(σt,B)
(3) B ≡ (...,(J0, T1, ...)) Ω(B,Υ(Υ(σ, T
(4) Π(σ,B) ≡ 0) , T1)...)
Où Ω est la fonction de transition d'état de finalisation de
bloc (une fonction qui récompense une partie désignée) ;Best
ce bloc, qui comprend une série de transactions parmi
d'autres composants ; et Π est la fonction de transition d'état
au niveau du bloc.
C'est la base du paradigme de la blockchain, un modèle qui constitue
l'épine dorsale non seulement d'Ethereum, mais de tous les systèmes de
transaction décentralisés basés sur le consensus à ce jour.
2.1.Valeur.Afin d'encourager le calcul au sein du réseau, il doit y
avoir une méthode convenue pour transmettre la valeur. Pour
résoudre ce problème, Ethereum dispose d'une monnaie
intrinsèque, Ether, également connue sous le nom deEPFet
parfois désigné par le vieil anglais D̄. La plus petite sous-
dénomination d'Ether, et donc celle dans laquelle toutes les
valeurs entières de la monnaie sont comptées, est le Wei. Un
éther est défini comme étant 1018Wei. Il existe d'autres sous-
dénominations d'Ether :
Multiplicateur Nom
dix0 Wei
dix12 Szabo
dix15 Finney
dix18 Éther
Tout au long du présent ouvrage, toute référence à la valeur, dans
le contexte de l'Ether, de la monnaie, d'un solde ou d'un paiement,
doit être supposée être comptée en Wei.
2.2.Quelle Histoire ?Étant donné que le système est décentralisé et
que toutes les parties ont la possibilité de créer un nouveau bloc sur
un ancien bloc préexistant, la structure résultante est nécessairement
une arborescence de blocs. Afin de former un consensus sur le
chemin, de la racine (le bloc de genèse) à la feuille (le bloc contenant
les transactions les plus récentes) à travers cette structure
arborescente, connue sous le nom de blockchain, il doit y avoir un
schéma convenu. S'il y a un désaccord entre les nœuds quant au
chemin de la racine à la feuille dans l'arborescence des blocs qui est le
"meilleur" blockchain, alors unfourchettese produit.
Cela signifierait qu'au-delà d'un point donné dans le temps
(bloc), plusieurs états du système peuvent coexister : certains
nœuds croyant qu'un bloc contient les transactions canoniques,
d'autres nœuds croyant qu'un autre bloc est canonique,
contenant potentiellement des transactions radicalement
différentes ou incompatibles. . Cela doit être évité à tout prix car
l'incertitude qui en résulterait tuerait probablement toute
confiance dans l'ensemble du système.
Le schéma que nous utilisons pour générer un consensus est
une version simplifiée du protocole GHOST introduit par
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ
Sompolinsky et Zohar [2013]. Ce processus est décrit en détail
dans la section 10.
3.Conventions
J'utilise un certain nombre de conventions typographiques pour la
notation formelle, dont certaines sont assez particulières au présent
travail :
Les deux ensembles de valeurs d'état hautement structurées, de
« niveau supérieur », sont indiqués par des lettres grecques
minuscules en gras. Ils tombent dans ceux de l'état-monde, qui sont
notésσ(ou une variante de celle-ci) et ceux de l'état machine,µ.
Les fonctions opérant sur des valeurs hautement structurées sont
désignées par une lettre grecque majuscule, par exemple Υ, la
fonction de transition d'état d'Ethereum.
Pour la plupart des fonctions, une lettre majuscule est utilisée, par
exemple C, la fonction de coût générale. Ceux-ci peuvent être indicés
pour désigner des variantes spécialisées, par exempleCSTORE, la fonction
de coût pour leSTOREopération. Pour les fonctions spécialisées et
éventuellement définies en externe, je peux formater comme du texte
de machine à écrire, par exemple la fonction de hachage Keccak-256
(selon l'entrée gagnante du concours SHA-3) est notéeKCE (et
généralement appelé Keccak ordinaire). AussiKEC512fait référence à la
fonction de hachage Keccak 512.
Les tuples sont généralement désignés par une lettre majuscule,
par exempleJ,est utilisé pour désigner une transaction Ethereum. Ce
symbole peut, s'il est défini en conséquence, être mis en indice pour faire
référence à un composant individuel, par exempleJn, désigne le nonce de
ladite transaction. La forme de l'indice est utilisée pour indiquer son type ;
par exemple, les indices majuscules font référence à des tuples avec des
composants inscriptibles.
Les scalaires et les séquences d'octets de taille fixe (ou, de manière
synonyme, les tableaux) sont désignés par une lettre minuscule
normale, par exemplenest utilisé dans le document pour désigner une
transaction nonce. Ceux qui ont une signification particulière peuvent
être grecs, par exempleδ, le nombre d'éléments requis sur la pile pour
une opération donnée.
Les séquences de longueur arbitraire sont généralement désignées par une
lettre minuscule en gras, par exempleoest utilisé pour désigner la séquence
d'octets donnée comme données de sortie d'un appel de message. Pour les
valeurs particulièrement importantes, une lettre majuscule en gras peut être
utilisée.
Partout, nous supposons que les scalaires sont des entiers positifs
et appartiennent donc à l'ensemblePL'ensemble de toutes les
séquences d'octets estB,formellement défini dans l'annexe B. Si un tel
ensemble de séquences est limité à celles d'une longueur particulière,
il est désigné par un indice, ainsi l'ensemble de toutes les séquences
d'octets de longueur 32 est nomméB32et l'ensemble de tous les entiers
positifs inférieurs à 2256est appeléP256. Ceci est formellement défini
dans la section 4.4.
Les crochets sont utilisés pour indexer et référencer des
composants individuels ou des sous-séquences de séquences, par
exemple µs[0] désigne le premier article sur la pile de la machine. Pour
les sous-séquences, des ellipses sont utilisées pour spécifier la plage
prévue, pour inclure des éléments aux deux limites, par exempleµm[0..
31] désigne les 32 premiers éléments de la mémoire de la machine.
Dans le cas de l'état globalσ, qui est une séquence de
comptes, eux-mêmes tuples, les crochets sont utilisés pour
référencer un compte individuel.
Lors de l'examen de variantes de valeurs existantes, je suis la
règle selon laquelle, dans un champ de définition donné, si nous
supposons que la valeur "d'entrée" non modifiée est désignée par
l'espace réservé - alors la valeur modifiée et utilisable est
désignée par -′, et les valeurs intermédiaires seraient -∗,
RÉVISION EIP-150 3
- ∗∗&c. Dans des occasions très particulières, afin de maximiser la lisibilité et
uniquement si la signification est sans ambiguïté, je peux utiliser des indices
alphanumériques pour désigner des valeurs intermédiaires, en particulier
celles qui sont particulièrement importantes.
Lors de l'examen de l'utilisation de fonctions existantes, étant
donné une fonctionF, la fonctionF∗désigne une version similaire,
élément par élément, du mappage de fonctions à la place entre les
séquences. Il est formellement défini dans la section 4.4.
Je définis un certain nombre de fonctions utiles tout au long.
L'un des plus courants est ,̀ qui s'évalue au dernier élément de la
séquence donnée :
(5) (X)≡X[‖X‖−1]
4.Blocs, état et transactions
Après avoir présenté les concepts de base derrière
Ethereum, nous discuterons plus en détail de la signification
d'une transaction, d'un bloc et de l'état.
4.1.État mondial.L'état du monde (État), est un mappage entre les adresses
(identificateurs de 160 bits) et les états de compte (une structure de
données sérialisée en tant que RLP, voir l'annexe B). Bien que non stocké
sur la blockchain, il est supposé que l'implémentation maintiendra ce
mappage dans un arbre Merkle Patricia modifié (essayer, voir Annexe D). Le
trie nécessite un backend de base de données simple qui maintient un
mappage des bytearrays aux bytearrays ; nous nommons cette base de
données sous-jacente la base de données d'état. Cela a un certain nombre
d'avantages; Premièrement, le nœud racine de cette structure dépend
cryptographiquement de toutes les données internes et, en tant que tel,
son hachage peut être utilisé comme une identité sécurisée pour
l'ensemble de l'état du système. Deuxièmement, étant une structure de
données immuable, elle permet de rappeler tout état précédent (dont le
hachage racine est connu) en modifiant simplement le hachage racine en
conséquence. Étant donné que nous stockons tous ces hachages racine
dans la blockchain, nous sommes en mesure de revenir trivialement aux
anciens états.
L'état du compte comprend les quatre champs suivants :
nonce :Une valeur scalaire égale au nombre de trans-
actions envoyées depuis cette adresse ou, dans le
cas de comptes avec code associé, le nombre de
créations de contrats effectuées par ce compte. Pour
compte d'adresseunen étatσ, cela serait
formellement notéσ[un]n.
équilibre:Une valeur scalaire égale au nombre de Wei
appartenant à cette adresse. Formellement désignéσ[un]b. racine
de stockage :Un hachage de 256 bits du nœud racine d'un
Arbre Merkle Patricia qui encode le contenu de
stockage du compte (un mappage entre des valeurs
entières 256 bits), encodé dans le trie comme un
mappage du hachage Keccak 256 bits des clés
entières 256 bits vers les 256- encodés RLP valeurs
entières de bits. Le hachage est formellement notéσ[
un]s. hachage de code :Le hachage du code EVM de ce
compte—c'est le code qui est exécuté si cette adresse reçoit
un appel de message ; il est immuable et donc,
contrairement à tous les autres champs, ne peut pas être
modifié après la construction. Tous ces fragments de code
sont contenus dans la base de données d'état sous leurs
hachages correspondants pour une récupération ultérieure.
Ce hachage est formellement notéσ[un]c, et donc le code
peut être noté commeb,étant donné queKEC(b) = σ[un]c.
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 4

Étant donné que je souhaite généralement faire référence non pas au hachage Limite de gaz :Une valeur scalaire égale au maximum
racine du trie, mais à l'ensemble sous-jacent de paires clé/valeur stockées à l'intérieur, quantité de gaz qui devrait être utilisée pour exécuter
Je définis une équivalence commode : cette transaction. Celle-ci est payée à l'avance, avant
( ) tout calcul et ne peut être augmentée ultérieurement ;
(6) TRIE L∗je(σ[un]s)≡σ[un]s
officiellementJg.
La fonction de réduction pour l'ensemble de paires clé/valeur dans pour:L'adresse 160 bits du destinataire de l'appel de message
l'épreuve,L∗je,est défini comme la transformation élément par élément ent ou, pour une opération de création de contrat,∅,utilisé
de la fonction de baseLje,donné comme : ici pour désigner le seul membre deB0;officiellement Jt.
( )( )
(7) Lje(k, v) ≡ KEC(k),RLP(v)
valeur:Une valeur scalaire égale au nombre de Wei à
où: être reversé au destinataire de l'appel de message
ou, en cas de création de contrat, en dotation sur le
(8) k∈B32 ∧v∈P compte nouvellement créé ; officiellementJv.
Il sera entendu queσ[un]sn'est pas un membre v, r, s :Valeurs correspondant à la signature de la
"physique" du compte et ne contribue pas à sa transaction et utilisées pour déterminer l'expéditeur
sérialisation ultérieure. de la transaction ; officiellementJw,JretJs. Ceci est
Si lacodeHash fichamp est le(e K ) hachage eccak-256 du développé dans l'annexe F.
chaîne vide, c'est-à-direσ[un]c=KCE () ,alors le nœud De plus, une transaction de création de contrat contient :
représente un compte simple, parfois appelé compte «
initialisation :Un tableau d'octets de taille illimitée spécifiant
sans contrat ».
Code EVM pour la procédure d'initialisation du compte,
Ainsi, nous pouvons définir une fonction d'effondrement de l'état du mondeLS:
formellementJje.
(9) LS(σ)≡ {p(un) :σ[un]6 =∅} initialiserest un fragment de code EVM ; ça retourne lecorps,
où un deuxième fragment de code qui s'exécute chaque fois que le
( ( )) compte reçoit un appel de message (soit via une transaction, soit
(dix) p(un)≡KEC(un),RLP (σ[un]n,σ[un]b,σ[un]s,σ[un]c) en raison de l'exécution interne de code).initialisern'est exécuté
Cette fonction,LS, est utilisé avec la fonction trie pour fournir qu'une seule fois lors de la création du compte et est supprimé
une courte identité (hachage) de l'état du monde. Nous immédiatement après.
En revanche, une transaction d'appel de message contient :
supposons:
données:Un tableau d'octets de taille illimitée spécifiant
(11) ∀un:σ[un] =∅∨(un∈B20∧v(σ[un]))
données d'entrée de l'appel de message, formellementJd.
oùvest la fonction de validité du compte : L'annexe F précise la fonction,S, qui mappe les
(12) v(X)≡Xn∈P256∧Xb∈P256∧Xs∈B32∧Xc∈B32 transactions à l'expéditeur, et passe par l'ECDSA de la courbe
SECP-256k1, en utilisant le hachage de la transaction (à
4.2.Propriété.Un numéro de bloc important pour la l'exception des trois derniers champs de signature) comme
compatibilité avec le réseau public est le bloc marquant la donnée à signer. Pour le moment, nous affirmons
transition entre leFrontièreetPropriétéphases de la plate- simplement que l'expéditeur d'une transaction donnéeJpeut
forme, que nous désignons par le symboleNH, défini ainsi être représenté avecS(J).

(14) {
(13) NH≡1,150,000
(Jn, Tp, Tg, Tt, Tv, Tje, Tw, Tr, Ts) (Jn, T siJt=∅
LJ(J)≡
Le protocole a été mis à jour à ce bloc, donc ce symbole apparaît dans p, Tg, Tt, Tv, Td, Tw, Tr, Ts) sinon
certaines équations pour tenir compte des changements.
Ici, nous supposons que tous les composants sont interprétés par
4.3.La transaction.Une transaction (officiellement,J) est une instruction le RLP comme des valeurs entières, à l'exception des tableaux d'octets
unique signée cryptographiquement construite par un acteur en de longueur arbitraireJjeetJd.
dehors du champ d'application d'Ethereum. Alors que l'on suppose
que l'acteur externe ultime sera de nature humaine, des outils
(15) Jn∈P256 ∧ Jv∈P256 ∧ Jp∈P256 ∧
logiciels seront utilisés dans sa construction et sa diffusion1. Il existe
Jg∈P256 ∧ Jw∈P5 ∧ Jr∈P256 ∧
deux types de transactions : celles qui se traduisent par des appels de
Js∈P256 ∧ Jd∈B ∧ Jje∈B
message et celles qui se traduisent par la création de nouveaux où
comptes avec code associé (appelées officieusement « création de
contrat »). Les deux types spécifient un certain nombre de champs (16) Pn={P:P∈P∧P <2n}
communs :
Le hachage d'adresseJtest légèrement différent : il s'agit soit d'un
nonce :Une valeur scalaire égale au nombre de trans- hachage d'adresse de 20 octets, soit, dans le cas d'une transaction de
actions envoyées par l'expéditeur ; officiellementJn. prix du création de contrat (et donc formellement égal à∅),c'est
gaz :Une valeur scalaire égale au nombre de la série d'octets vide RLP et donc le membre deB0:
Wei à payer par unité degazpour tous les frais de {
calcul encourus du fait de l'exécution de cette B20 siJt6 =∅
(17) Jt∈
transaction ; officiellementJp. B0 sinon

1Notamment, ces « outils » pourraient finalement devenir si causalement éloignés de leur initiation basée sur l'homme - ou les humains peuvent devenir si causalement neutres - qu'il
pourrait y avoir un point où ils pourraient être considérés à juste titre comme des agents autonomes. par exemple, les contrats peuvent offrir des primes aux humains pour avoir envoyé
des transactions pour initier leur exécution.
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 5

4.4.Le bloc.Le bloc dans Ethereum est la collection un blocB:

d'informations pertinentes (connu sous le nom de bloc
entête),H, ainsi que les informations correspondant aux
transactions comprises,T,et un ensemble d'autres en-
têtes de bloctuqui sont connus pour avoir un parent égal
au parent du parent du bloc actuel (ces blocs sont appelés
ommers2). L'en-tête du bloc contient plusieurs
informations :
hachage parent :Le hachage Keccak 256 bits du par-
l'en-tête du bloc ent, dans son intégralité ; officiellement
Hp. ommersHash :Le hachage Keccak 256 bits de l'om-
partie de liste mers de ce bloc ; officiellementHo.
Bénéficiaire:L'adresse 160 bits à laquelle tous les frais
collectées à partir de l'exploitation minière réussie de ce bloc
soient transférées ; officiellementHc.
étatRoot :Le hachage Keccak 256 bits de la racine
nœud du trie d'état, une fois toutes les transactions
exécutées et les finalisations appliquées ; officiellement
Hr. transactionsRoot :Le hachage Keccak 256 bits du
le nœud racine de la structure d'arbres rempli avec
chaque transaction dans la partie de liste de
transactions du bloc ; officiellementHt.
reçusRoot :Le hachage Keccak 256 bits de la racine
le nœud de la structure d'arbres rempli avec les
reçus de chaque transaction dans la partie de liste
de transactions du bloc ; officiellementHe.
logsBloom :Le filtre Bloom composé d'in-
des informations dexables (adresse de l'enregistreur et rubriques du journal)
contenues dans chaque entrée du journal à partir de la réception de chaque
transaction dans la liste des transactions ; officiellement Hb.
(18) B≡(BH,BJ,Btu)
4.4.1.Reçu de transaction.Afin d'encoder des informations sur
une transaction pour laquelle il peut être utile de constituer
une preuve à connaissance zéro, ou d'indexer et de
rechercher, nous encodons un reçu de chaque transaction
contenant certaines informations concernant son exécution.
Chaque reçu, notéBR[je] pour lejeème transaction) est placé
dans un trie indexé et la racine enregistrée dans l'en-tête
comme He.
Le reçu de transaction est un tuple de quatre éléments
comprenant l'état post-transaction,Rσ, le gaz cumulé
utilisé dans le bloc contenant le reçu de transaction
immédiatement après la transaction,Rtu, l'ensemble des
journaux créés lors de l'exécution de la transaction,Rje
et le filtre Bloom composé à partir des informations contenues dans ces
journaux,Rb:
(19) R≡(Rσ,Rtu,Rb,Rje)
La fonctionLRprépare trivialement un reçu de transaction
pour être transformé en un tableau d'octets sérialisé RLP :
(20) LR(R)≡(TRIE(LS(Rσ)),Rtu,Rb,Rje)
donc l'état post-transaction,Rσest encodé dans une structure en
trie, dont la racine constitue le premier élément.
Nous affirmonsRtu, le gaz cumulé utilisé est un entier
positif et que les logs Bloom,Rb, est un hachage de taille 2048
bits (256 octets) :

(21) Rtu∈P∧Rb∈B256
difficulté:Une valeur scalaire correspondant à la différence
niveau de difficulté de ce bloc. Cela peut être calculé à partir Les entrées du journal,Rje, est une série d'entrées de journal, appelées,
du niveau de difficulté du bloc précédent et de l'horodatage; par exemple, (O0,O1, ...). Une entrée de journal,O, est un tuple de l'adresse
officiellementHd. d'un logger,Oun, une série de rubriques de journal de 32 octets,Ot
nombre:Une valeur scalaire égale au nombre d'an- et un certain nombre d'octets de données,Od:
blocs cestor. Le bloc de genèse a un nombre de zéro ;
(22) O≡(Oun,(Ot0,Ot1, ...),Od)
officiellementHje.
Limite de gaz :Une valeur scalaire égale à la limite actuelle
des dépenses de gaz par bloc ; officiellementHje. (23) Oun∈B20 ∧ ∀t∈Ot:t∈B32 ∧Od∈B
gazutilisé :Une valeur scalaire égale au gaz total utilisé
Nous définissons la fonction filtre Bloom,M, pour réduire une entrée de
dans les transactions de ce bloc ; officiellementHg.
journal en un seul hachage de 256 octets :
horodatage :Une valeur scalaire égale au raisonnable
sortie de time() d'Unix au début de ce bloc ; ∨( )
(24) M(O)≡ M3:2048(t)
officiellementHs.
t∈{Oun}∪Ot
extraData :Un tableau d'octets arbitraire contenant
données pertinentes pour ce bloc. Celui-ci doit être de 32 octets oùM3:2048est un filtre Bloom spécialisé qui définit trois bits sur
ou moins ; officiellementHX. 2048, étant donné une série d'octets arbitraires. Pour ce faire, il
mixHash :Un hachage de 256 bits qui s'avère combiné prend les 11 bits de poids faible de chacune des trois premières
du moment qu'une quantité suffisante de calcul a paires d'octets dans un hachage Keccak-256 de la série d'octets.
été effectuée sur ce bloc ; officiellement Hm. Officiellement:

nonce :Un hachage 64 bits qui s'avère combiné avec (25)M3:2048(x : x∈B) ≡ y : y∈B256 où:
le mix-hash qu'une quantité suffisante de calcul a (26) y = (0,0, ...,0) sauf:
été effectuée sur ce bloc ; officiellement Hn. (27) : Bm(X,je)(y) =1
∀je∈{0,2,4}
(28) m(X, je) ≡ KEC(X)[je, je+1] mod 2048

Les deux autres composants du bloc sont simplement une oùBest la fonction de référence du bit telle queBj(X) est égal au
liste d'en-têtes de bloc ommer (du même format que ci-dessus) et bit d'indexj(indexé à partir de 0) dans le tableau d'octets
une série de transactions. Formellement, on peut se référer à X.

2ommerest le terme non sexiste le plus courant (qui ne dit pas grand-chose) pour signifier « frère ou sœur du parent » ; voirhttp://nonbinary.org/wiki/
Gender_neutral_language#Family_Terms
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 6

4.4.2.Validité holistique.Nous pouvons affirmer la validité d'un 4.4.4.Validité de l'en-tête de bloc.Nous définissonsP(BH) pour être le
bloc si et seulement s'il satisfait plusieurs conditions : il doit bloc parent deB, formellement :
être cohérent en interne avec les hachages de bloc ommer et
(37) P(H)≡B′:KEC(RLP(B′ H)) =Hp
transaction et les transactions donnéesBJ(comme spécifié
dans la sec 11), lorsqu'il est exécuté dans l'ordre sur l'état de Le numéro de bloc est le numéro de bloc du parent
baseσ(dérivé de l'état final du bloc parent), résulte en un incrémenté de un :
nouvel état de l'identitéHr: (29)
(38) Hje≡P(H)Salut+1

Hr ≡ TRIE(LS(Π(σ,B))) ∧ La difficulté canonique d'un bloc d'en-têteHest défini

Ho ≡ KEC(RLP(L∗H(Btu))) ∧ commeD(H):
Ht ≡ TRIE({∀je <‖BJ‖,je∈P :p(je,LJ(BJ[je]))}) J ∧ (39)
-
He ≡ ∨RIE({∀(je <)‖BR‖,je∈P :p(je,LR(BR[je]))}) ∧ --D0 si Hje = 0
( )
Hb ≡ r∈BR rb D(H)≡ maximumD 0 ,P (H ) HD+X × ς1+ε si Hje<NH
-- ( )
oùp(k, v) est simplement la transformation RLP par maximumD0,P(H)HD+X × ς2+ε sinon
paires, dans ce cas, la première étant l'index de la où:
transaction dans le bloc et la seconde étant le reçu de la
(40) D0≡131072
transaction :
( ) ⌊ ⌋
(30) p(k, v)≡RLP(k),RLP(v) P(H)HD
(41) X≡
2048
En outre: {
1 si H s< P(H) Hs + 13
(31) TRIE(LS(σ)) =P(BH)Heure (42) ς1≡
− 1 sinon
AinsiTRIE(LS(σ)) est le hachage du nœud racine de ( ⌊ ⌋ )
l'arborescence Merkle Patricia contenant les paires clé-valeur H-P
s (H ) Hs
(43) ς2≡maximum 1− , − 99
de l'étatσavec des valeurs codées à l'aide de RLP, etP(BH) est dix
le bloc parent deB, défini directement. ⌊ ⌋
Les valeurs issues du calcul des transactions, (44) ε≡2bHje÷100000c−2
notamment les reçus de transaction,BR, et celle définie par
la fonction d'accumulation d'état des transactions, Π, sont La limite de gaz canoniqueHjed'un bloc d'en-têteHdevoir
formalisées plus loin dans la section 11.4. remplir la relation :
⌊ ⌋
P(H)Hl
(45) Hje<P(H)Hl+ ∧
4.4.3.Sérialisation.La fonctionLBetLHsont respectivement les 1024
⌊ ⌋
fonctions de préparation d'un bloc et d'un en-tête de bloc. P(H)Hl
Tout comme la fonction de préparation des reçus de
(46) Hje>P(H)Hl− ∧
1024
transactionLR, nous affirmons les types et l'ordre de la (47) Hje>125000
structure lorsque la transformation RLP est requise :
Hsest l'horodatage du blocHet doit satisfaire la
(32)LH(H) ≡ (Hp,Ho,Hc,Hr,Ht,He,Hb,Hd, relation :
Hje,Hje,Hg,Hs,HX,Hm,Hn) (
) (48) Hs>P(H)Hs
∗
(33) LB(B) ≡ LH(BH),L∗ J(BJ),LH(Btu)
Ce mécanisme impose une homéostasie en termes de temps
AvecL∗ JetLHétant∗la trans- séquence élément par élément entre les blocs ; une période plus courte entre les deux derniers
formations, donc : blocs entraîne une augmentation du niveau de difficulté et donc
(34) )( )
des calculs supplémentaires nécessaires, allongeant la période
F∗( (X0, X1, ...)≡F(X0), F(X1), ... pour toute fonctionF suivante probable. Inversement, si la période est trop grande, la
difficulté et le temps prévu jusqu'au bloc suivant sont réduits.
Les types de composants sont définis ainsi : Le nonce,Hn, doit satisfaire les relations :
2256
(35) Hp∈B32 ∧ Ho∈B32 ∧ Hc∈B20 ∧ (49) n6 ∧m=Hm
Hr∈B32 ∧ Ht∈B32 ∧ He∈B32 ∧ Hd
Hb∈B256 ∧ Hd∈P ∧ Hje∈P ∧ avec (n,m) =PoW(Hn,Hn,d).
Hje∈P ∧ Hg∈P ∧ Hs∈P256 ∧ OùHn est l'en-tête du nouveau blocH, maissans les
HX∈B ∧ Hm∈B32 ∧ Hn∈B8 composants nonce et mix-hash,détant le DAG actuel, un grand
ensemble de données nécessaire pour calculer le mix-hash, et
où
PoWest la fonction de preuve de travail (voir la section 11.5) : elle
(36) Bn={B:B∈B∧‖B‖=n} s'évalue en un tableau avec le premier élément étant le mixhash,
pour prouver qu'un DAG correct a été utilisé, et le deuxième
Nous avons maintenant une spécification rigoureuse pour la élément étant un nombre pseudo-aléatoire cryptographiquement
construction d'une structure de bloc formelle. La fonction RLPRLP dépendant deHetd.Étant donné une distribution
(voir l'annexe B) fournit la méthode canonique pour approximativement uniforme dans la plage [0,264), le temps
transformer cette structure en une séquence d'octets prête à attendu pour trouver une solution est proportionnel à la
être transmise sur le fil ou stockée localement. difficulté, Hd.
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ
C'est le fondement de la sécurité de la blockchain et c'est la
raison fondamentale pour laquelle un nœud malveillant ne peut
pas propager des blocs nouvellement créés qui, autrement,
écraseraient ("réécriraient") l'historique. Étant donné que le
nonce doit satisfaire à cette exigence et que sa satisfaction
dépend du contenu du bloc et, à son tour, de ses transactions
composées, la création de nouveaux blocs valides est difficile et,
au fil du temps, nécessite approximativement la puissance de
calcul totale de la partie fiable de les pairs miniers.
Ainsi, nous sommes en mesure de définir la validité de l'en-tête de bloc
fonctionV(H):
2256
(50)V(H)≡ n6 ∧ m=H m ∧
Hd
(51) Hd=D(H) ∧ intrinsèque. Ceux-ci inclus:
(52) Hg≤Hje ∧ (1) La transaction est bien formée RLP, sans octets de fin
⌊ ⌋
P(H)Hl
(53) Hje < P(H)Hl+
1024
⌊ ⌋
P(H)Hl
(54) Hje>P(H)Hl−
1024
(55) Hje>125000∧
(56) Hs>P(H)Hs ∧ (5) le solde du compte de l'expéditeur contient au moins
(57) Hje=P(H)Salut+1 ‖HX ∧
(58) ‖ ≤32
où (n,m) =PoW(Hn,Hn,d)
Notant en outre queextraDatadoit être au maximum de 32
octets.
5.Gaz et paiement
Afin d'éviter les problèmes d'abus de réseau et d'éviter les
questions inévitables découlant de l'exhaustivité de Turing,
tous les calculs programmables dans Ethereum sont soumis à
des frais. Le barème des frais est spécifié en unités de gaz(
voir l'annexe G pour les frais associés aux divers calculs).
Ainsi, tout fragment donné de calcul programmable (cela
inclut la création de contrats, les appels de messages,
l'utilisation et l'accès au stockage de compte et l'exécution
d'opérations sur la machine virtuelle) a un coût
universellement convenu en termes de gaz.
Chaque transaction est associée à une quantité spécifique de
gaz :GasLimit.Il s'agit de la quantité de gaz qui est implicitement
achetée à partir du solde du compte de l'expéditeur. L'achat a lieu
au momentprix du gaz,également spécifié dans la transaction. La
transaction est considérée comme invalide si le solde du compte
ne peut pas supporter un tel achat. Il s'appelleGasLimitpuisque
tout gaz non utilisé à la fin de la transaction est remboursé (au
même tarif d'achat) sur le compte de l'expéditeur. Le gaz n'existe
pas en dehors de l'exécution d'une transaction. Ainsi, pour les
comptes associés à un code de confiance, une limite de gaz
relativement élevée peut être définie et laissée telle quelle.
En général, l'Ether utilisé pour acheter du gaz non remboursé est
livré auBénéficiaireadresse, l'adresse d'un compte généralement sous
le contrôle du mineur. Les agents sont libres de spécifier n'importe
quelprix du gazqu'ils souhaitent, mais les mineurs sont libres d'ignorer
les transactions comme ils le souhaitent. Un prix du gaz plus élevé sur
une transaction coûtera donc plus cher à l'expéditeur en termes
d'éther et offrira une plus grande valeur au mineur et sera donc plus
susceptible d'être sélectionné pour être inclus par plus de mineurs.
Les mineurs, en général, choisiront d'annoncer le prix minimum du
gaz pour lequel
RÉVISION EIP-150 7
ils exécuteront des transactions et les opérateurs seront
libres de solliciter ces prix pour déterminer le prix du gaz à
offrir. Puisqu'il y aura une distribution (pondérée) des prix
minimaux acceptables du gaz, les opérateurs auront
nécessairement un compromis à faire entre la baisse du prix
du gaz et la maximisation des chances que leur transaction
soit exploitée en temps opportun.
6.Exécution des transactions
L'exécution d'une transaction est la partie la plus
complexe du protocole Ethereum : elle définit la fonction de
transition d'état Υ. Il est supposé que toute transaction
exécutée passe d'abord les tests initiaux de validité
supplémentaires ;
∧ (2) la signature de la transaction est valide ;
(3) le nonce de la transaction est valide (équivalent au nonce
actuel du compte de l'expéditeur) ;
∧
(4) la limite de gaz n'est pas inférieure au gaz intrinsèque, g0,
utilisé par la transaction ;
le coût,v0, requis en paiement initial.
Formellement, on considère la fonction Υ, avecJétant
une transaction etσl'état:
(59) σ′= Υ(σ, T)
Ainsiσ′est l'état post-transactionnel. On définit aussi Υgpour évaluer
la quantité de gaz utilisée dans l'exécution d'une transaction et Υjepour
évaluer les éléments de journal accumulés de la transaction, les deux
devant être formellement définis ultérieurement.
6.1.Sous-état.Tout au long de l'exécution de la transaction, nous
accumulons certaines informations qui sont utilisées immédiatement
après la transaction. Nous appelons celasous-état de transaction, et le
représenter commeUN, qui est un tuple :
(60) UN≡(UNs,UNje,UNr)
Le contenu du tuple comprendUNs, l'ensemble suicide : un
ensemble de comptes qui seront supprimés une fois la transaction
terminée.UNjeest la série de journaux : il s'agit d'une série de "points
de contrôle" archivés et indexables dans l'exécution du code VM qui
permettent aux appels de contrat d'être facilement suivis par des
spectateurs extérieurs au monde Ethereum (tels que les applications
frontales décentralisées). Enfin il y aUNr, le solde du remboursement,
augmenté grâce à l'utilisation duSTOREinstruction afin de réinitialiser
le stockage du contrat à zéro à partir d'une valeur non nulle. Bien qu'il
ne soit pas immédiatement remboursé, il est autorisé à compenser
partiellement les coûts d'exécution totaux.
Par souci de brièveté, nous définissons le sous-état videUN0pour ne pas avoir
de suicides, pas de journaux et un solde de remboursement nul :
(61) UN0≡(∅,(),0)
6.2.Exécution.Nous définissons le gaz intrinsèqueg0, la quantité de gaz
que cette transaction nécessite d'être payée avant l'exécution, comme
suit :
{
∑ gtxdatazero sije=0
(62) g0≡
je∈T,jeT gtxdatanonzero sinon
{d
gtxcreate siJt=∅∧ Hje≥N sinon H
(63) +
0
(64) + gtransaction
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 8

oùJje, Tddésigne la série d'octets des données associées
à la transaction et du code EVM d'initialisation, selon que
la transaction concerne la création de contrat ou l'appel
de message.gtxcreateest ajouté si la transaction crée un
contrat, mais pas si un résultat de code EVM ou avant la
Transition de la ferme.gest entièrement défini à l'annexe
G.
Le coût initialv0est calculé comme suit :
(65) v0≡JgJp+Jv
La validité est déterminée comme suit :
du comptoir de remboursement à l'expéditeur au tarif d'origine.
⌊Jg−g′⌋
(72) g∗≡g′+min{ , UNr}
2
Le montant total remboursable est le gaz légitimement
restantg′, ajouté àUNr, cette dernière composante étant
plafonnée à un maximum de la moitié (arrondi à l'inférieur)
du montant total utiliséJg−g′.
L'Ether pour le gaz est remis au mineur, dont l'adresse
est précisée comme bénéficiaire du présent bloc B. On
définit donc l'état pré-finalσ∗en termes d'état provisoireσP:

(66) S(J)6 =∅∧

σ[S(J)]6 =∅∧ (73) σ∗ ≡σP sauf
Jn =σ[S(J)]n ∧ (74) σ∗[S(J)]b ≡σP[S(J)]b+g∗Jp
g06Jg∧ (75) σ∗[m]b ≡σP[m]b+ (Jg−g∗)Jp
v0 6σ[S(J)]b ∧
(76) m≡BHc
Jg 6BHl−(̀BR)tu
L'état final,σ′, est atteint après la suppression de tous les comptes qui
Notez l'état final; la somme de la limite de gaz de la
apparaissent dans la liste des suicides :
transaction,Jg, et le gaz utilisé dans ce bloc précédent, donné par (̀
BR)tu, ne doit pas être supérieur à celui du bloclimite de gaz, (77) σ′ ≡σ∗ sauf
BHl. (78) ∀je∈UNs:σ′[je]≡∅
L'exécution d'une transaction valide commence par un
changement irrévocable apporté à l'état : le nonce du compte Et enfin, on précise Υg, le gaz total utilisé dans cette
de l'expéditeur,S(J), est incrémenté de un et le solde est réduit transaction et Υje, les journaux créés par cette transaction :
d'une partie du coût initial,JgJp. Le gaz disponible pour le (79) Υg(σ, T) ≡ Jg−g′
calcul en cours,g, est défini commeJg−g0. Le calcul, qu'il
(80) Υje(σ, T) ≡ UNje
s'agisse d'une création de contrat ou d'un appel de message,
aboutit à un état éventuel (qui peut légalement être Ceux-ci sont utilisés pour aider à définir le reçu de transaction,
équivalent à l'état actuel), dont le passage est déterministe et discuté plus tard.
jamais invalide : il ne peut y avoir de transactions invalides à
partir de ce point. 7.Création de contrat
Nous définissons l'état du point de contrôleσ0: Il existe un certain nombre de paramètres intrinsèques
(67) σ0 ≡σsauf: utilisés lors de la création d'un compte : expéditeur (s), l'agent
d'origine (o), gaz disponible (g), prix du gaz (p), donation (v)
(68) σ0[S(J)]b ≡ σ[S(J)]b− JgJp
avec un tableau d'octets de longueur arbitraire,je,le code EVM
(69) σ0[S(J)]n ≡ σ[S(J)]n+1 d'initialisation et enfin la profondeur actuelle de la pile
ÉvaluationσPdepuisσ0dépend du type de transaction ; messagecall/contract-creation (e).
soit création de contrat soit appel de message ; on définit Nous définissons formellement la fonction de création comme
le tuple d'état provisoire post-exécutionσP,gaz restantg′et la fonction Λ, qui s'évalue à partir de ces valeurs, ainsi que de
sous-étatUN: l'étatσau tuple contenant le nouvel état, le gaz restant et le sous-
(70) état de transaction accumulé (σ′, g′,UN), comme dans la section 6 :
-
-Λ(σ ,ST0 , ( )Jo,
--
g, Tp, Tv, Tje,0) siJt=∅ (81) (σ′, g′,UN)≡Λ(σ, s, o, g, p, v,je, e)
(σP,g′,UN)≡
-Θ3(σ0, S(J), To, L'adresse du nouveau compte est définie comme étant les
-
Jt, Tt, g, Tp, Tv, Tv, Td,0) sinon 160 bits les plus à droite du hachage Keccak du codage RLP
oùgest la quantité de gaz restant après déduction du de la structure ne contenant que l'expéditeur et le nonce.
montant de base requis pour payer l'existence de la Ainsi, nous définissons l'adresse résultante pour le nouveau
transaction : compteun:
(( ( )))
(71) g≡Jg−g0 (82) un≡B96..255KEC RLP (s,σ[s]n−1)
etJoest le transacteur d'origine, qui peut différer de l'expéditeur oùKECest la fonction de hachage Keccak 256 bits,RLPest la
dans le cas d'un appel de message ou d'une création de contrat fonction de codage RLP,Bun B(X) est évalué à une valeur binaire
non directement déclenché par une transaction mais provenant contenant les bits d'indices dans la plage [un B] des données
de l'exécution du code EVM. binairesXetσ[X] est l'état de l'adresse deXou∅s'il n'en existe pas.
Notez que nous utilisons Θ3pour indiquer le fait que seules les trois Notez que nous utilisons un de moins que la valeur nonce de
premières composantes de la valeur de la fonction sont prises ; la finale l'expéditeur ; nous affirmons que nous avons incrémenté le nonce
représente la valeur de sortie de l'appel de message (un tableau d'octets) et du compte de l'expéditeur avant cet appel, et donc la valeur
n'est pas utilisée dans le contexte de l'évaluation des transactions. utilisée est le nonce de l'expéditeur au début de la transaction
responsable ou de l'opération VM.
Après le traitement de l'appel de message ou de la création du Le nonce du compte est initialement défini comme zéro, le solde
contrat, l'état est finalisé en déterminant le montant à comme la valeur transmise, le stockage comme vide et le hachage de
rembourser,g∗du gaz restant,g′, plus une allocation code comme le hachage Keccak 256 bits de la chaîne vide ;
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 9

le solde de l'expéditeur est également réduit de la valeur l'état est autorisé à persister. Ainsi formellement, nous pouvons
transmise. Ainsi l'état muté devientσ∗: spécifier l'état résultant, le gaz et le sous-état comme (σ′, g′,UN) où:

(83) σ∗≡σsauf:
(97)
( ( ))
(84) σ∗ [un]≡ 0, v+v′,TRIE(∅),KCE () -
-0 si σ∗∗=∅
(85) σ∗[s]b ≡ σ[s]b−v
g′≡g∗∗ si g∗∗<c∧ Hje<NH
oùv′est la valeur préexistante du compte, dans le cas où
--
g∗∗−c sinon
il existait auparavant :
{ (98)
0 siσ[un] =∅ -
(86) v′≡ -σ si σ∗∗=∅
σ[un]b sinon --σ∗∗ si g∗∗<c∧ Hje<NH
σ′≡
Enfin, le compte est initialisé par l'exécution du code EVM - sauf:
--σ∗∗
d'initialisationjeselon le modèle d'exécution (voir section 9). σ′[un]c=KEC(o) sinon
L'exécution du code peut affecter plusieurs événements qui
ne sont pas internes à l'état d'exécution : le stockage du L'exception dans la détermination deσ′dicte que
compte peut être modifié, d'autres comptes peuvent être o,la séquence d'octets résultante de l'exécution du code
créés et d'autres appels de message peuvent être effectués. d'initialisation, spécifie le code de corps final pour le compte
En tant que tel, la fonction d'exécution de code Ξ s'évalue à nouvellement créé.
un tuple de l'état résultantσ∗∗, gaz disponible restantg∗∗, le Notez que l'intention de blocNHÀ partir de (Propriété) est
sous-état accumuléUNet le code corps du compteo. que le résultat est soit un nouveau contrat créé avec succès
avec sa dotation, soit aucun nouveau contrat sans transfert
de valeur. AvantPropriété, s'il n'y a pas assez d'essence pour
(87) (σ∗∗, g∗∗,UN,o)≡Ξ(σ∗, g, je) payerc, un compte à l'adresse du nouveau contrat est créé,
oùjecontient les paramètres de l'environnement d'exécution tels avec tous les effets secondaires de l'initialisation, et la valeur
que définis à la section 9, c'est-à-dire : est transférée, mais aucun code de contrat n'est déployé.

(88) jeun ≡ un 7.1.Subtilités.Notez que pendant l'exécution du code

(89) jeo ≡ o d'initialisation, l'adresse nouvellement créée existe mais sans
(90) jep ≡ p code de corps intrinsèque. Ainsi tout appel de message reçu par
celui-ci pendant ce temps ne provoque l'exécution d'aucun code.
(91) jed ≡ ()
Si l'exécution de l'initialisation se termine par unSUICIDE
(92) jes ≡ s instruction, la question est sans objet puisque le compte sera
(93) jev ≡ v supprimé avant que la transaction ne soit terminée. Pour une
(94) jeb ≡ je normaleARRÊTcode, ou si le code renvoyé est autrement vide,
alors l'état est laissé avec un compte zombie, et tout solde restant
(95) jee ≡ e
sera verrouillé dans le compte pour toujours.
jeds'évalue au tuple vide car il n'y a pas de données d'entrée
pour cet appel.jeHn'a pas de traitement particulier et est
déterminé à partir de la blockchain.
8.Message Appel
L'exécution du code épuise le gaz, et le gaz ne peut pas descendre Dans le cas de l'exécution d'un appel de message, plusieurs
en dessous de zéro, ainsi l'exécution peut se terminer avant que le paramètres sont nécessaires : expéditeur (s), auteur de la transaction (
code ne soit arrivé à un état d'arrêt naturel. Dans ce (et plusieurs o), destinataire (r), le compte dont le code doit être exécuté (c,
autres) cas exceptionnels, nous disons qu'une exception Out-of-Gas généralement le même que le destinataire), gaz disponible (g), valeur (
s'est produite : l'état évalué est défini comme étant l'ensemble vide,∅, v) et le prix du gaz (p) avec un tableau d'octets de longueur arbitraire,
et l'ensemble de l'opération de création ne devrait avoir aucun effet d,les données d'entrée de l'appel et enfin la profondeur actuelle de la
sur l'état, le laissant effectivement tel qu'il était immédiatement avant pile message-appel/contrat-création (e).
de tenter la création. Outre l'évaluation d'un nouvel état et d'un sous-état de transaction, les
Si le code d'initialisation se termine avec succès, un coût appels de message ont également un composant supplémentaire : les
final de création de contrat est payé, le coût de dépôt de données de sortie indiquées par le tableau d'octetso.Ceci est ignoré lors de
code, c, proportionnelle à la taille du code du contrat créé : l'exécution des transactions, mais des appels de message peuvent être
lancés en raison de l'exécution du code VM et dans ce cas, ces informations
(96) c≡gdépôt de code×|o|
sont utilisées.
S'il ne reste pas assez de gaz pour payer cela, c'est-à-dire g∗∗<c
, nous déclarons également une exception Out-of-Gas. (99) (σ′, g′,UN,o)≡Θ(σ, s, o, r, c, g, p, v, ṽ,d, e)
Le gaz restant sera nul dans une telle condition exceptionnelle,
Notez que nous devons faire la différence entre la valeur qui
c'est-à-dire que si la création a été réalisée à la réception d'une
doit être transférée,v, à partir de la valeur apparente dans le
transaction, cela n'affecte pas le paiement du coût intrinsèque de la
contexte d'exécution,ṽ, pour leAPPEL DÉLÉGUÉinstruction.
création du contrat ; il est payé quoi qu'il en soit. Cependant, la valeur
Nous définissonsσ1, le premier état de transition comme état
de la transaction n'est pas transférée à l'adresse du contrat avorté
d'origine mais avec la valeur transférée de l'expéditeur au
lorsque nous sommes en panne d'essence.
destinataire :
Si une telle exception ne se produit pas, le gaz restant
est remboursé à l'initiateur et le gaz désormais modifié (100) σ1[r]b≡σ[r]b+v∧σ1[s]b≡σ[s]b−v
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 dix

Tout au long du présent travail, on suppose que si σ1[r] un paramètre,gaz, ce qui limite la quantité totale de
n'était pas défini à l'origine, il sera créé en tant que compte calculs effectués.
sans code ni état et sans solde ni nonce. Ainsi, l'équation
précédente doit être interprétée comme signifiant : 9.1.Bases.L'EVM est une architecture simple basée sur la pile. La taille
(101) σ1≡σ′ 1 sauf: de mot de la machine (et donc la taille de l'élément de pile) est de 256
bits. Cela a été choisi pour faciliter le schéma de hachage Keccak-256
(102) σ1[s]b≡σ′ s]b−v
1[ et les calculs de courbe elliptique. Le modèle de mémoire est un
simple tableau d'octets adressés par mot. La pile a une taille maximale
(103) etσ′ 1 ≡σsauf: de 1024. La machine dispose également d'un modèle de stockage
{ indépendant ; c'est un concept similaire à la mémoire mais plutôt
σ′1[r]≡(v,0,KEC(()),TRIE(∅)) siσ[r] =∅ qu'un tableau d'octets, c'est un tableau de mots adressables par mot.
(104)
σ′1[r]b≡σ[r]b+v sinon Contrairement à la mémoire, qui est volatile, le stockage est non
volatile et est maintenu dans le cadre de l'état du système. Tous les
Le code associé au compte (identifié comme le fragment dont le
emplacements dans le stockage et la mémoire sont bien définis
hachage Keccak estσ[c]c) est exécuté selon le modèle d'exécution (voir
initialement comme zéro.
section 9). Tout comme pour la création de contrat, si l'exécution
La machine ne suit pas l'architecture standard de von Neumann.
s'arrête de manière exceptionnelle (c'est-à-dire en raison d'une
Plutôt que de stocker le code de programme dans une mémoire ou un
alimentation en gaz épuisée, d'un débordement de pile, d'une
stockage généralement accessible, il est stocké séparément dans une
destination de saut invalide ou d'une instruction invalide), alors aucun
ROM virtuelle interagissant uniquement via une instruction
gaz n'est remboursé à l'appelant et l'état est rétabli au point
spécialisée.
immédiatement avant le transfert de solde (c'est-à-direσ).
La machine peut avoir une exécution exceptionnelle pour plusieurs
{ raisons, notamment des dépassements de capacité de pile et des
σ siσ∗∗=∅ instructions invalides. Comme l'exception hors gaz (OOG), ils ne
(105) σ′ ≡ σ∗∗ sinon laissent pas les changements d'état intacts. Au lieu de cela, la machine
- s'arrête immédiatement et signale le problème à l'agent d'exécution
-Ξ
-ECREC(σ1, g, je) si r=1 (soit le processeur de transaction, soit, de manière récursive,
--ΞSHA256(σ1, g, je) si r=2 l'environnement d'exécution de génération) qui le traitera
(106()σ∗∗, g′,s,o) ≡ Ξ (σ1, g, je)
-RIP160 si r=3 séparément.
--ΞIDENTIFIANT(σ1, g, je) si r=4
- 9.2.Aperçu des frais.Les redevances (libellées en gaz) sont
Ξ(σ1, g, je) sinon
facturées dans trois circonstances distinctes, toutes trois
(107) jeun ≡ r préalables à l'exécution d'une opération. Le premier et le plus
(108) jeo ≡ o courant est la redevance intrinsèque au calcul de l'opération
(109) jep ≡ p (voir annexe G). Deuxièmement, le gaz peut être déduit afin
de constituer le paiement d'un appel de message subordonné
(110) jed ≡ d
ou de la création d'un contrat ; cela fait partie du paiement
(111) jes ≡ s pourCRÉEZ, APPELEZetCODE D'APPEL.Enfin, le gaz peut être payé
(112) jev ≡ ṽ en raison d'une augmentation de l'utilisation de la mémoire.
(113) jee ≡ e
Au cours de l'exécution d'un compte, les frais totaux pour
(114) LaissezKEC(jeb) = σ[c]c
l'utilisation de la mémoire à payer sont proportionnels au plus petit
On suppose que le client aura stocké la paire (KEC(jeb), multiple de 32 octets requis de sorte que tous les indices de mémoire
JEb) à un moment donné afin de déterminerjebréalisable. (que ce soit pour la lecture ou l'écriture) sont inclus dans la plage. Ceci
est payé sur une base juste à temps; en tant que tel, référencer une
Comme on peut le voir, il existe quatre exceptions à zone de mémoire d'au moins 32 octets supérieure à toute mémoire
l'utilisation du cadre général d'exécution Ξ pour l'évaluation de précédemment indexée entraînera certainement des frais d'utilisation
l'appel de message : il s'agit de quatre contrats dits « précompilés de mémoire supplémentaires. En raison de ces frais, il est très peu
», entendus comme une architecture préliminaire pouvant probable que les adresses dépassent les limites de 32 bits. Cela dit, les
devenir ultérieurementextensions natives. Les quatre contrats implémentations doivent être capables de gérer cette éventualité.
aux adresses 1, 2, 3 et 4 exécutent respectivement la fonction de Les frais de stockage ont un comportement légèrement nuancé - pour
récupération de clé publique à courbe elliptique, le schéma de inciter à la minimisation de l'utilisation du stockage (qui correspond
hachage SHA2 256 bits, le schéma de hachage RIPEMD 160 bits et directement à une base de données d'état plus grande sur tous les nœuds),
la fonction d'identité. les frais d'exécution pour une opération qui efface une entrée dans le
Leur définition formelle complète se trouve à l'annexe E. stockage ne sont pas seulement annulés, un qualifié le remboursement est
accordé ; en fait, ce remboursement est effectivement payé à l'avance
9.Modèle d'exécution puisque l'utilisation initiale d'un emplacement de stockage coûte nettement
Le modèle d'exécution spécifie comment l'état du système est plus cher que l'utilisation normale.
modifié en fonction d'une série d'instructions de bytecode et d'un Voir l'annexe H pour une définition rigoureuse du coût du gaz
petit tuple de données environnementales. Ceci est spécifié via un EVM.
modèle formel d'une machine à états virtuelle, connue sous le
nom de machine virtuelle Ethereum (EVM). C'est unquasi-Machine 9.3.Environnement d'exécution.En plus de l'état du
complète de Turing ; lequasiqualification vient du fait que le calcul systèmeσ, et le gaz restant pour le calculg, plusieurs
est intrinsèquement borné par informations importantes sont utilisées dans
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 11

l'environnement d'exécution que l'agent d'exécution doit Notez que nous devons supprimer la quatrième valeur dans le
fournir ; ceux-ci sont contenus dans le tupleje: tuple renvoyé parXpour évaluer correctement Ξ, d'où l'indice
• jeun, l'adresse du compte propriétaire du code en X0,1,2,4.
cours d'exécution. Xest donc cyclé (récursivement ici, mais on s'attend
• jeo, l'adresse de l'expéditeur de la transaction à l'origine généralement à ce que les implémentations utilisent une simple
de cette exécution. boucle itérative) jusqu'à ce que soitZdevient vrai indiquant que
• jep, le prix du gaz dans la transaction à l'origine l'état actuel est exceptionnel et que la machine doit être arrêtée
de cette exécution. et toute modification ignorée ou jusqu'à ce queHdevient une série
• jed, le tableau d'octets qui est la donnée d'entrée de (plutôt que l'ensemble vide) indiquant que la machine a atteint un
cette exécution ; si l'agent d'exécution est une arrêt contrôlé.
transaction, il s'agirait des données de transaction.
• jes, l'adresse du compte qui a provoqué l'exécution 9.4.1.État de la machine.L'état des machinesµest défini comme le
du code ; si l'agent d'exécution est une transaction, tuple (g, pc,m, je,s)quels sont les gaz disponibles, le compteur de
ce serait l'expéditeur de la transaction. programmespc∈P256,le contenu de la mémoire, le nombre actif de
• jev, la valeur, en Wei, passée sur ce compte dans le mots en mémoire (en comptant en continu à partir de la position
cadre de la même procédure que l'exécution ; si 0) et le contenu de la pile. Le contenu de la mémoireµmsont une
l'agent d'exécution est une transaction, ce serait la suite de zéros de taille 2256.
valeur de la transaction. Pour faciliter la lecture, les mnémoniques d'instructions, écrits en
• jeb, le tableau d'octets qui est le code machine à petites majuscules (ex.AJOUTER),doivent être interprétés comme leurs
exécuter. équivalents numériques ; le tableau complet des consignes et leurs
• jeH, l'en-tête de bloc du bloc actuel. spécificités est donné en annexe H.
• jee, la profondeur de l'appel de message actuel ou de la Aux fins de définirZ,HetO, nous définissonsw
création de contrat (c'est-à-dire le nombre deAPPELs ou comme opération courante à exécuter :
CRÉERs en cours d'exécution actuellement).
{
jeb[µpc] siµpc<‖jeb‖
Le modèle d'exécution définit la fonction Ξ, qui peut (125) w≡
ARRÊT sinon
calculer l'état résultantσ′, le gaz restantg′, la liste des suicides
s,la série de journauxje,les remboursementsret la sortie qui Nous supposons également les montants fixes deδetα,
en résulte,o,étant donné ces définitions : spécifiant les éléments de pile supprimés et ajoutés, tous deux
(115) (σ′, g′,s,je, r,o)≡Ξ(σ, g, je) inscriptibles sur l'instruction et une fonction de coût d'instruction
C évaluer le coût total, en gaz, de l'exécution de l'instruction
9.4.Présentation de l'exécution.Il faut maintenant définir la donnée.
fonction Ξ. Dans la plupart des implémentations pratiques, cela
sera modélisé comme une progression itérative de la paire 9.4.2.Arrêt exceptionnel.La fonction d'arrêt exceptionnelleZ
comprenant l'état complet du système,σet l'état de la machine, µ.
Pour- est défini comme:
généralement, nous le définissons récursivement avec une Ce
fonctionX. utilise une fonction d'itérationO(qui définit le résultat (126) Z(σ,µ,je)≡µg<C(σ,µ,je)∨
d'un seul cycle de la machine d'état) ainsi que des fonctions Zqui δw=∅∨
détermine si l'état actuel est un état d'arrêt exceptionnel de la ‖µs‖ < δw ∨
machine etH, spécifiant les données de sortie de l'instruction si et (w∈ {SAUT,JUMPI} ∧
seulement si l'état actuel est un état d'arrêt normal de la µs[0]∈/ D(jeb))∨
machine. ‖µs‖− δw+αw>1024
La séquence vide, notée (), n'est pas égale à l'ensemble Ceci indique que l'exécution est dans un état d'arrêt
vide, noté∅ ;ceci est important lors de l'interprétation de la exceptionnel s'il n'y a pas suffisamment de gaz, si l'instruction est
sortie deH, qui s'évalue à∅lorsque l'exécution doit continuer invalide (et donc saδl'indice n'est pas défini), s'il n'y a pas
mais une série (potentiellement vide) lorsque l'exécution doit suffisamment d'éléments de pile, si unSAUT/SAUTdestination n'est
s'arrêter. pas valide ou la nouvelle taille de pile serait supérieure à 1024. Le
( )
(116) Ξ(σ, g, je) ≡ X0,1,2,4 (σ,µ,UN0, JE) lecteur avisé se rendra compte que cela implique qu'aucune
instruction ne peut, par son exécution, provoquer un arrêt
(117) µg ≡ g
exceptionnel.
(118) µpc ≡ 0
(119) µm ≡ (0,0, ...) 9.4.3.Validité de la destination de saut.Nous utilisions auparavantD
(120) µje ≡ 0 comme fonction pour déterminer l'ensemble de destinations de saut
valides compte tenu du code en cours d'exécution. Nous définissons
(121) µs ≡ ()
cela comme toute position dans le code occupée par unJUMPDEST
(122) instruction.
-( )
- , , JE,() si Z(σ,µ,je) Toutes ces positions doivent être sur des limites d'instruction
( ) -∅µ,UN0
X(σ,µ,un, je)≡ O(σ,µ,un, je)·o si o6=∅ valides, plutôt que de se trouver dans la partie données dePOUSSER
-( ) opérations et doit apparaître dans la partie explicitement définie
XO(σ,µ,un, je) sinon
du code (plutôt que dans la partie implicitement définie
où ARRÊTopérations qui le suivent).

(123) o ≡ H(µ,je) Officiellement:

(124) (un, b, c)·d ≡ (a B c d) (127) D(c)≡DJ(c,0)

 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 12

où: arriver à la feuille. Cela s'apparente aux schémas existants, tels que
(128) - ceux utilisés dans les protocoles dérivés de Bitcoin.
-{} si je>|c| Puisqu'un en-tête de bloc inclut la difficulté, l'en-tête
DJ(c, je)≡ {je} ∪ D J(cN, (je,c [je])) si c[je] =JUMPDEST seul suffit à valider le calcul effectué. Tout bloc contribue
-- au calcul total oudifficulté totaled'une chaîne.
DJ(c,N(je,c[je])) sinon
oùNest la prochaine position d'instruction valide dans le code, en Ainsi nous définissons la difficulté totale du blocBrécursivement
sautant les données d'unPOUSSERinstruction, le cas échéant : (129) comme :
{ (141) Bt ≡ B′t+Bd
je+w-PUSH1 +2 je+1 siw∈[PUSH1,PUSH32]
N(je, w)≡ (142) B′ ≡ P(BH)
sinon
En tant que tel étant donné un blocB,Btest sa difficulté totale,B
9.4.4.Arrêt normal.La fonction d'arrêt normaleHest défini: ′est son bloc parent etBdest sa difficulté.

(130) 11.Finalisation du bloc

-
-HRETOUR(µ) si w=RETOUR Le processus de finalisation d'un bloc comporte quatre étapes :
H(µ,je)≡() si w∈ {ARRÊT,SUICIDE}
-- (1) Valider (ou, si l'exploitation minière, déterminer) ommers ;
∅ sinon (2) valider (ou, si l'exploitation minière, déterminer) les transactions ;

L'opération d'arrêt de retour de données,RETOUR,a une (3) appliquer des récompenses ;

fonction spécialeHRETOUR, défini à l'annexe H. (4) vérifier (ou, si l'extraction, calculer un état valide) et
nonce.
9.5.Le cycle d'exécution.Les éléments de la pile sont ajoutés ou supprimés
de la partie la plus à gauche et la plus faiblement indexée du
11.1.Validation Ommer.La validation des en-têtes ommer
série; tous les autres éléments restent inchangés :
ne signifie rien de plus que de vérifier que chaque en-tête
( ) ommer est à la fois un en-tête valide et satisfait la relation
(131) O(σ,µ,un, je) ≡ (σ′,µ′,UN′, JE) deNommer de e génération au bloc actuel où
(132) ∆ ≡ αw− δw N≤6. Le maximum d'en-têtes ommer est de deux. Officiellement:
∧
(133) ‖µ′s‖ ≡ ‖µs‖+∆ (143) ‖Btu‖62 V(tu)∧k(EN HAUT(BH)H,6)
(134) ∀X∈[αw,‖µ′ s‖) :µ′ s[X] ≡ µs[X+∆] tu∈Btu

Le gaz est réduit du coût en gaz de l'instruction et pour la oùkdésigne la propriété "is-kin":
plupart des instructions, le compteur de programme (144) -
s'incrémente à chaque cycle, pour les trois exceptions, nous -FAUX sin=0
supposons une fonction J, indicé par l'une des deux instructions, k(U, H, n)≡ s(EUH)
qui s'évalue à la valeur correspondante : --
∨k(EN HAUT(H)H, n−1) sinon
(135) µ′g ≡ µg− C(σ,µ,je)
etsdénote la propriété « is-sibling » :
-
-JSAUT(µ) si w=SAUT (145)
(136) µ′pc ≡ J (µ)
-JUMPI si w=JUMPI s(EUH)≡(P(H) =P(tu)∧H6 =tu∧tu∈ /B(H)tu)
- oùB(H) est le bloc de l'en-tête correspondantH.
N(µpc,w) sinon
En général, nous supposons que la mémoire, la liste des suicides et l'état du 11.2.Validation des transactions.Le donnégazUtilisé
système ne changent pas : doivent correspondre fidèlement aux transactions
(137) µ′m ≡ répertoriées :BHg, le gaz total utilisé dans le bloc, doit être
µm
égal au gaz cumulé utilisé selon la transaction finale :
(138) µ′je ≡ µje
(146) BHg= (̀R)tu
(139) UN′ ≡ UN
(140) σ′ ≡ σ 11.3.Demande de récompense.L'application de récompenses à un bloc
consiste à augmenter le solde des comptes de l'adresse bénéficiaire
Cependant, les instructions modifient généralement un ou
du bloc et de chaque ommer d'un certain montant. Nous augmentons
plusieurs composants de ces valeurs. Les composants modifiés
le compte bénéficiaire du bloc enRb; pour chaque ommer, nous
répertoriés par instruction sont notés dans l'annexe H, à côté des
augmentons le bénéficiaire du bloc d'un montant supplémentaire1de
valeurs pour αetδet une description formelle des besoins en gaz.
la récompense de32bloc et le bénéficiaire de l'ommer est récompensé

dix.Blocktree à Blockchain en fonction du nombre de blocs. Formellement nous définissons la

fonction Ω :
La blockchain canonique est un chemin de la racine à la feuille
à travers l'ensemble de l'arborescence des blocs. Afin d'avoir un
(147) Ω(B,σ) ≡ σ′:σ′=σ sauf:
consensus sur le chemin dont il s'agit, conceptuellement, nous ‖B‖tu
(148)σ′[BHc]b = σ[BHc]b+ (1 + ) Rb
identifions le chemin qui a fait l'objet du plus de calculs, ou, le le 32
plus lourdchemin. Il est clair qu'un facteur qui aide à déterminer (149)∀tu∈Btu:
le chemin le plus lourd est le numéro de bloc de la feuille, 1
σ′[tuc]b = σ[tuc]b+ (1 + (U-B
je Salut) ) Rb
équivalent au nombre de blocs, sans compter le bloc de genèse 8
non miné, dans le chemin. Plus le chemin est long, plus l'effort S'il y a des collisions des adresses de bénéficiaires entre
minier total qui doit avoir été fait pour les ommers et le bloc (c'est-à-dire deux ommers avec le
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 13

même adresse de bénéficiaire ou un ommer avec la même adresse de 11.5.Preuve de travail minière.La preuve de travail minière (PoW)
bénéficiaire que le bloc actuel), les ajouts sont appliqués existe en tant que nonce cryptographiquement sécurisé qui
cumulativement. prouve au-delà de tout doute raisonnable qu'une quantité
Nous définissons la récompense de bloc comme 5 Ether : particulière de calcul a été dépensée dans la détermination d'une
certaine valeur de jetonn. Il est utilisé pour renforcer la sécurité
(150) LaisserRb=5×dix18
de la blockchain en donnant du sens et du crédit à la notion de
difficulté (et, par extension, de difficulté totale). Cependant, étant
11.4.Validation d'état et de nonce.Nous pouvons maintenant
donné que l'extraction de nouveaux blocs s'accompagne d'une
définir la fonction, Γ, qui cartographie un blocBà son état
récompense, la preuve de travail fonctionne non seulement
d'initiation : (151) {
comme une méthode garantissant que la blockchain restera
σ0 siP(BH) =∅ canonique à l'avenir, mais également comme un mécanisme de
Γ(B)≡
σje:TRIE(LS(σje)) =P(BH)Heure sinon répartition des richesses.
Pour ces deux raisons, la fonction de preuve de travail a deux
Ici,TRIE(LS(σje)) signifie le hachage du nœud racine d'un trie
objectifs importants ; premièrement, il doit être le plus accessible
d'étatσje; on suppose que les implémentations stockeront cela
possible au plus grand nombre. L'exigence ou la récompense de
dans la base de données d'état, trivial et efficace puisque le trie
matériel spécialisé et peu commun doit être minimisée. Cela rend
est par nature une structure de données immuable.
le modèle de distribution aussi ouvert que possible et,
Et enfin définir Φ, la fonction de transition de bloc, qui idéalement, fait de l'acte d'extraction un simple échange de
cartographie un bloc incompletBà un bloc complet B′: l'électricité vers l'éther à peu près au même rythme pour
n'importe qui dans le monde.
(152) Φ(B) ≡ B ′: B′=B∗ sauf: Deuxièmement, il ne devrait pas être possible de faire des
2256 profits super-linéaires, et surtout pas avec une barrière initiale
(153)B′ n = n: X6 élevée. Un tel mécanisme permet à un adversaire bien financé de
Hd
gagner une partie gênante de la puissance minière totale du
(154)B′ m =mavec (x,m) =PoW(Bn ∗,n,d)
réseau et, en tant que tel, lui donne une récompense super-
(155) B∗≡Bsauf:B∗ r=r(Π(Γ(B),B)) linéaire (faisant ainsi la distribution en sa faveur) tout en
réduisant la sécurité du réseau.
Avecdétant un jeu de données tel que spécifié dans l'annexe J.
L'un des fléaux du monde Bitcoin est les ASIC. Ce sont des pièces
Comme spécifié au début du présent travail, Π est la fonction
de matériel de calcul spécialisées qui n'existent que pour effectuer une
de transition d'état, qui est définie en termes de Ω, la fonction de
seule tâche. Dans le cas de Bitcoin, la tâche est la fonction de hachage
finalisation de bloc et Υ, la fonction d'évaluation de transaction,
SHA256. Alors que les ASIC existent pour une fonction de preuve de
toutes deux maintenant bien définies.
travail, les deux objectifs sont mis en péril. Pour cette raison, une
Comme détaillé précédemment,R[n]σ,R[n]jeetR[n]tusont les
fonction de preuve de travail résistante aux ASIC (c'est-à-dire difficile
nème états correspondants, logs et gaz cumulés consommés
ou économiquement inefficace à mettre en œuvre dans du matériel de
après chaque transaction (R[n]b, le quatrième composant du
calcul spécialisé) a été identifiée comme la solution miracle
tuple, a déjà été défini en termes de logs). Le premier est
proverbiale.
défini simplement comme l'état résultant de l'application de
Deux directions existent pour la résistance ASIC ; tout d'abord,
la transaction correspondante à l'état résultant de la
rendez-le séquentiel à mémoire dure, c'est-à-dire concevez la fonction
transaction précédente (ou l'état initial du bloc dans le cas de
de telle sorte que la détermination du nonce nécessite beaucoup de
la première de ces transactions) :
mémoire et de bande passante de sorte que la mémoire ne puisse pas
{
Γ(B) sin <0 être utilisée en parallèle pour découvrir plusieurs nonces
(156) R[n]σ= simultanément. La seconde consiste à rendre le type de calcul dont il
Υ(R[n−1]σ,BJ[n]) sinon
aurait besoin pour un usage général ; le sens de « matériel spécialisé »
Dans le cas dBR[n]tu, nous adoptons une approche similaire en pour un ensemble de tâches à usage général est, naturellement, du
définissant chaque élément comme le gaz utilisé pour évaluer la matériel à usage général et, en tant que tels, les ordinateurs de
transaction correspondante additionnée à l'élément précédent (ou bureau de base sont susceptibles d'être assez proches du « matériel
zéro, s'il s'agit du premier), nous donnant un total cumulé : spécialisé » pour la tâche. Pour Ethereum 1.0, nous avons choisi le
- premier chemin.
-0 sin <0 Plus formellement, la fonction de preuve de travail prend la forme
(157)R[n]tu= Υg(R[n−1] σ,BJ[n]) dePoW :
-- (160)
+ R[n−1]tu sinon 2256
m=Hm ∧n6 avec (m, n) =PoW(Hn,Hn,d)
PourR[n]je, on utilise le Υjefonction que nous avons commodément Hd
définie dans la fonction d'exécution de transaction.
OùHn est l'en-tête du nouveau bloc maissansles composants
(158) R[n]je= Υje(R[n−1]σ,BJ[n]) nonce et mix-hash ;Hnest le nonce de l'en-tête ;dest un grand
ensemble de données nécessaire pour calculer le mix-Hash etHd
Enfin, nous définissons Π comme le nouvel état compte tenu de la est la valeur de difficulté du nouveau bloc (c'est-à-dire la difficulté
fonction de récompense de bloc Ω appliquée à l'état résultant de la du bloc de la section 10).PoWest la fonction de preuve de travail
(̀BR)σ:
transaction finale, qui évalue à un tableau avec le premier élément étant le mixHash
et le deuxième élément étant un nombre pseudo-aléatoire
(159) Π(σ,B)≡Ω(B, `(R)σ)
cryptographiquement dépendant deHetd. L'algorithme sous-
Ainsi, le mécanisme complet de transition de bloc, moins PoW, jacent s'appelle Ethash et est décrit ci-dessous.
la fonction de preuve de travail est définie.
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ
11.5.1.Éthash.Ethash est l'algorithme PoW prévu pour Ethereum
1.0. Il s'agit de la dernière version de Dagger-Hashimoto,
introduite par Buterin [2013b] et Dryja [2014], bien qu'elle ne
puisse plus être appelée de manière appropriée, car de
nombreuses caractéristiques originales des deux algorithmes ont
été radicalement modifiées au cours du dernier mois de
recherche. et développement. L'itinéraire général emprunté par
l'algorithme est le suivant :
Il existe une graine qui peut être calculée pour chaque bloc en
parcourant les en-têtes de bloc jusqu'à ce point. A partir de la graine,
on peut calculer un cache pseudo-aléatoire,Jcache initoctets en taille
initiale. Les clients légers stockent le cache. A partir du cache, nous
pouvons générer un jeu de données, Jdatasetinitoctets en taille initiale,
avec la propriété que chaque élément de l'ensemble de données ne
dépend que d'un petit nombre d'éléments du cache. Les clients
complets et les mineurs stockent l'ensemble de données. L'ensemble
de données croît linéairement avec le temps.
L'exploitation minière consiste à saisir des tranches aléatoires de
l'ensemble de données et à les hacher ensemble. La vérification peut être
effectuée avec peu de mémoire en utilisant le cache pour régénérer les
éléments spécifiques de l'ensemble de données dont vous avez besoin,
vous n'avez donc qu'à stocker le cache. Le grand ensemble de données est
mis à jour une fois parJépoqueblocs, de sorte que la grande majorité des
efforts d'un mineur consistera à lire l'ensemble de données, et non à y
apporter des modifications. Les paramètres mentionnés ainsi que
l'algorithme sont expliqués en détail dans l'annexe J.
12.Mise en œuvre des contrats
Il existe plusieurs modèles d'ingénierie des contrats qui permettent des
comportements utiles particuliers ; deux d'entre eux dont je parlerai
brièvement sont les flux de données et les nombres aléatoires.
12.1.Flux de données.Un contrat de flux de données est un
contrat qui fournit un service unique : il donne accès à des
informations du monde extérieur au sein d'Ethereum.
L'exactitude et l'actualité de ces informations ne sont pas
garanties et c'est la tâche d'un auteur de contrat secondaire - le
contrat qui utilise le flux de données - de déterminer le degré de
confiance qui peut être accordé à un seul flux de données.
Le modèle général implique un contrat unique au sein
d'Ethereum qui, lorsqu'il reçoit un appel de message, répond
avec des informations opportunes concernant un
phénomène externe. Un exemple pourrait être la
température locale de New York. Cela serait mis en œuvre
sous la forme d'un contrat renvoyant la valeur d'un point de
stockage connu. Bien sûr, ce point de stockage doit être
maintenu avec la bonne température, et donc la deuxième
partie du modèle serait qu'un serveur externe exécute un
nœud Ethereum, et immédiatement à la découverte d'un
nouveau bloc, crée une nouvelle transaction valide, envoyée
au contrat, mettant à jour ladite valeur en stockage. Le code
du contrat n'accepterait de telles mises à jour qu'à partir de
l'identité contenue sur ledit serveur.
12.2.Nombres aléatoires.Fournir des nombres aléatoires dans un
système déterministe est, naturellement, une tâche impossible.
Cependant, nous pouvons approximer avec des nombres pseudo-
aléatoires en utilisant des données qui sont généralement
inconnues au moment de la transaction. Ces données peuvent
inclure le hachage du bloc, l'horodatage du bloc et l'adresse du
bénéficiaire du bloc. Afin de rendre difficile pour les mineurs
malveillants de contrôler ces valeurs, il faut utiliser leBLOCHASH
opération afin d'utiliser les hachages des 256 blocs précédents comme
nombres pseudo-aléatoires. Pour une série de tels nombres,
RÉVISION EIP-150 14
une solution triviale serait d'ajouter une quantité constante et
de hacher le résultat.
13.Directions futures
La base de données d'état ne sera pas obligée de conserver toutes les
structures de trie d'état passées dans le futur. Il doit maintenir un âge pour
chaque nœud et éventuellement supprimer les nœuds qui ne sont ni assez
récents ni les points de contrôle ; des points de contrôle, ou un ensemble de
nœuds dans la base de données qui permettent de traverser le trie d'état
d'un bloc particulier, pourraient être utilisés pour imposer une limite
maximale à la quantité de calcul nécessaire pour récupérer n'importe quel
état dans la blockchain.
La consolidation de la blockchain pourrait être utilisée afin de
réduire la quantité de blocs qu'un client devrait télécharger pour
agir comme un nœud minier complet. Une archive compressée
de la structure de trie à des moments donnés (peut-être un bloc
sur 10 000) pourrait être conservée par le réseau de pairs,
refondant efficacement le bloc de genèse. Cela réduirait la
quantité à télécharger dans une seule archive plus une limite
maximale stricte de blocs.
Enfin, la compression de la blockchain pourrait peut-être être
effectuée : les nœuds dans l'état trie qui n'ont pas envoyé/reçu une
transaction dans un nombre constant de blocs pourraient être rejetés,
réduisant à la fois les fuites d'Ether et la croissance de la base de
données d'état.
13.1.Évolutivité.L'évolutivité reste une préoccupation éternelle. Avec
une fonction de transition d'état généralisée, il devient difficile de
partitionner et de paralléliser les transactions pour appliquer la
stratégie diviser pour mieux régner. Sans réponse, la plage de valeur
dynamique du système reste essentiellement fixe et à mesure que la
valeur moyenne des transactions augmente, les moins précieuses
d'entre elles sont ignorées, étant économiquement inutiles à inclure
dans le grand livre principal. Cependant, plusieurs stratégies existent
qui peuvent potentiellement être exploitées pour fournir un protocole
considérablement plus évolutif.
Une certaine forme de structure hiérarchique, obtenue soit en
consolidant de petites chaînes plus légères dans le bloc principal, soit
en construisant le bloc principal par la combinaison et l'adhésion
incrémentielles (par preuve de travail) d'ensembles de transactions
plus petits, peut permettre la parallélisation de la combinaison de
transactions et de la construction de blocs . Le parallélisme pourrait
également provenir d'un ensemble prioritaire de chaînes de blocs
parallèles, consolidé chaque bloc et avec des transactions en double
ou invalides rejetées en conséquence.
Enfin, le calcul vérifiable, s'il est rendu généralement disponible et
suffisamment efficace, peut fournir une voie permettant à la preuve
de travail d'être la vérification de l'état final.
14.Conclusion
J'ai présenté, discuté et défini formellement le protocole
d'Ethereum. Grâce à ce protocole, le lecteur peut implémenter un
nœud sur le réseau Ethereum et en rejoindre d'autres dans un
système d'exploitation social sécurisé décentralisé. Des contrats
peuvent être rédigés afin de spécifier de manière algorithmique
et d'appliquer de manière autonome des règles d'interaction.
15.Remerciements
Un grand merci à Aeron Buchanan pour l'auteur des révisions
de Homestead, Christoph Jentzsch pour l'auteur de l'algorithme
Ethash et Yoichi Hirai pour avoir fait la plupart des
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 15

Modifications EIP-150. Une maintenance importante, des corrections {https://en.wikipedia.org/wiki/Fowler%E2%80%

utiles et des suggestions ont été fournies par un certain nombre
d'autres personnes de l'organisation Ethereum DEV et de la
communauté Ethereum dans son ensemble, notamment Gustav
Simonsson, Pawel Bylica, Jutta Steiner, Nick Savers, Viktor Trón, Marko
Simovic, Giacomo Tazzari et, bien sûr, Vitalik Buterin.
Les références
93Noll%E2%80%93Vo_hash_function#cite_note-2}. Nils
Gura, Arun Patel, Arvinderpal Wander, Hans Eberle,
et Sheueling Chang Shantz. Comparaison de la cryptographie à
courbe elliptique et du RSA sur des processeurs 8 bits. Dans
Matériel cryptographique et systèmes embarqués-CHES 2004,
pages 119–132. Springer, 2004.
Sergio Demian Lerner. Fonction de hachage dur de la mémoire stricte

Jacob Aron. Le logiciel BitCoin trouve une nouvelle vie.Nouvelle Scien- tions. 2014. URL {http://www.hashcash.org/papers/
tiste, 213(2847):20, 2012. memohash.pdf}.
Adam Retour. Hashcash - Amortissable Publiquement Auditable Marc Miller. L'avenir du droit. Danspapier remis au
Fonctions de coût. 2002. URL {http://www.hashcash. Conférence Extra 3 (9 août), 1997.
org/papers/amortizable.pdf}. Satoshi Nakamoto. Bitcoin : une monnaie électronique peer-to-peer
Roman Boutellier et Mareike Heinzen. Pirates, Pionniers, système.Consulté, 1:2012, 2008.
Innovateurs et imitateurs. DansCroissance par l'innovation, Meni Rosenfeld. Vue d'ensemble des pièces colorées. 2012. URL
pages 85–96. Springer, 2014. {https://bitcoil.co.il/BitcoinX.pdf}. Yonatan
Vitalik Buterin. Ethereum : une puce de nouvelle génération Sompolinsky et Aviv Zohar. Accél-
Plate-forme d'application contractuelle et décentralisée. erant le traitement des transactions de Bitcoin. Rapide

2013a. URL {http://ethereum.org/ethereum.html}.
Vitalik Buterin. Dagger : une mémoire difficile à calculer,
Memory-Facile à vérifier Scrypt Alternative. 2013b. URL
{http://vitalik.ca/ethereum/dagger.html}. Thaddée
Dryja. Hashimoto : preuve de travail liée aux E/S.
2014. URL {https://mirrorx.com/files/hashimoto. pdf}.
Cynthia Dwork et Moni Naor. Tarification via le traitement ou
lutter contre le courrier indésirable. DansDans la 12e conférence
internationale annuelle sur la cryptologie, pages 139–147, 1992.
Phong Vo Glenn Fowler, Se poser sur Sec
Fonction de hachage FowlerNollVo. 1991.
L'argent pousse sur les arbres, pas sur les chaînes, URL
2013. {CryptologieePrintArchive,Report2013/881}.
http://eprint.iacr.org/.
Simon Sprankel. Base technique des monnaies numériques,
2013.
Nick Szabo. Formaliser et sécuriser les relations sur
réseaux publics.Premier lundi, 2(9), 1997.
Vivek Vishnumurthy, Sangeeth Chandrakumar et
Emin Gn Sirer. Karma : Un cadre économique sécurisé pour le
partage de ressources entre pairs, 2003.
Noll. JR Willet. Spécification complète de MasterCoin. 2013. URL
URL {https://github.com/mastercoin-MSC/spec}.

annexeUN.Terminologie
Acteur externe :Une personne ou une autre entité capable de s'interfacer avec un nœud Ethereum, mais extérieure au monde de
Ethereum. Il peut interagir avec Ethereum en déposant des transactions signées et en inspectant la blockchain et l'état
associé. A un (ou plusieurs) comptes intrinsèques.
Adresse:Un code de 160 bits utilisé pour identifier les comptes.
Compte:Les comptes ont un solde intrinsèque et un nombre de transactions maintenu dans le cadre de l'état Ethereum.
Ils ont également un code EVM (éventuellement vide) et un état de stockage (éventuellement vide) qui leur sont
associés. Bien qu'homogène, il est logique de distinguer deux types pratiques de comptes : ceux avec un code
EVM associé vide (ainsi le solde du compte est contrôlé, le cas échéant, par une entité externe) et ceux avec un
code EVM associé non vide (donc le compte représente un Objet Autonome). Chaque compte a une adresse
unique qui l'identifie.
Transaction:Une donnée, signée par un Acteur Externe. Il représente soit un Message soit une nouvelle Autonome
Objet. Les transactions sont enregistrées dans chaque bloc de la blockchain.
Objet Autonome :Un objet notionnel existant uniquement dans l'état hypothétique d'Ethereum. A une valeur intrinsèque
adresse et donc un compte associé ; le compte aura un code EVM associé non vide. Incorporé uniquement en
tant qu'état de stockage de ce compte.
État de stockage :Les informations propres à un compte donné qui sont conservées entre les moments où le
Le code EVM associé au compte s'exécute.
Message:Les données (sous la forme d'un ensemble d'octets) et la valeur (spécifiée comme Ether) qui sont transmises entre deux comptes, soit
par le fonctionnement déterministe d'un Objet Autonome ou la signature cryptographiquement sécurisée de la
Transaction.
Message d'appel :Action de transmettre un message d'un Compte à un autre. Si le compte de destination est associé
avec un code EVM non vide, alors la VM sera démarrée avec l'état dudit objet et le message traité. Si l'expéditeur
du message est un objet autonome, l'appel transmet toutes les données renvoyées par l'opération VM.

Gaz:L'unité de coût de réseau fondamentale. Payé exclusivement par Ether (à partir de PoC-4), qui est converti librement
vers et depuis le gaz selon les besoins. Le gaz n'existe pas en dehors du moteur de calcul interne d'Ethereum ; son prix est fixé
par la transaction et les mineurs sont libres d'ignorer les transactions dont le prix du gaz est trop bas.
Contracter:Terme informel utilisé pour désigner à la fois un morceau de code EVM qui peut être associé à un compte ou un
Objet autonome.
Objet:Synonyme d'objet autonome.
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 16

Application :Une application visible par l'utilisateur final hébergée dans le navigateur Ethereum.
Navigateur Ethereum : (alias Ethereum Reference Client) Une interface graphique multiplateforme d'une interface similaire à une interface simplifiée
navigateur (à la Chrome) capable d'héberger des applications en bac à sable dont le backend est purement sur le protocole
Ethereum.
Machine virtuelle Ethereum : (alias EVM) La machine virtuelle qui constitue la partie clé du modèle d'exécution
pour le code EVM associé à un compte.
Environnement d'exécution Ethereum : (alias ERE) L'environnement qui est fourni à un objet autonome
s'exécutant dans l'EVM. Inclut l'EVM mais aussi la structure de l'état mondial sur lequel l'EVM s'appuie pour
certaines instructions d'E/S, notamment CALL & CREATE.
Code EMV :Le bytecode que l'EVM peut exécuter nativement. Utilisé pour spécifier formellement le sens et les rami-
fications d'un message à un Compte.
Assemblage EVM :La forme lisible par l'homme du code EVM.
JE VAIS:Le langage de bas niveau de type Lisp, un langage inscriptible par l'homme utilisé pour la rédaction de contrats simples et généraux
boîte à outils de langage de bas niveau pour la trans-compilation vers.

annexeBPréfixe de longueur récursif

Il s'agit d'une méthode de sérialisation pour coder des données binaires arbitrairement structurées (tableaux d'octets).
On définit l'ensemble des structures possiblesT :

(161) J ≡ L ∪B
(162) L ≡ {t : t = (t[0],t[1], ...)∧ ∀n<‖t‖t[n]∈J} {b : b = (b[0],
(163) B ≡ b[1], ...)∧ ∀n<‖b‖b[n]∈O}
OùOest l'ensemble des octets. AinsiBest l'ensemble de toutes les séquences d'octets (autrement appelés tableaux d'octets, et une feuille si elle est imaginée comme un
arbre),Lest l'ensemble de toutes les (sous-)structures arborescentes qui ne sont pas une seule feuille (un nœud de branche s'il est imaginé comme un arbre) etJest
l'ensemble de tous les tableaux d'octets et de telles séquences structurelles.
Nous définissons la fonction RLP commeRLPà travers deux sous-fonctions, la première gérant l'instance lorsque la valeur est un
tableau d'octets, le second lorsqu'il s'agit d'une séquence de valeurs supplémentaires :
{
Rb(X) siX∈B
(164) RLP(X)≡
Rje(X) sinon

Si la valeur à sérialiser est un tableau d'octets, la sérialisation RLP prend l'une des trois formes suivantes :
• Si le tableau d'octets ne contient qu'un seul octet et que cet octet est inférieur à 128, alors l'entrée est exactement égale
à la sortie.
• Si le tableau d'octets contient moins de 56 octets, alors la sortie est égale à l'entrée préfixée par l'octet égal à la
longueur du tableau d'octets plus 128.
• Sinon, la sortie est égale à l'entrée préfixée par le tableau d'octets de longueur minimale qui, lorsqu'il est interprété comme un
entier gros-boutien, est égal à la longueur du tableau d'octets d'entrée, qui est lui-même préfixé par le nombre d'octets requis
pour fidèlement encoder cette valeur de longueur plus 183.
Formellement, on définitRb:
-
-X si‖X‖=1∧X[0]<128 sinon
(165) Rb(X) ≡ (128 +‖X‖)·X si‖X‖ <56 sinon
-( ∥ ∥)
183 +∥ÊTRE(‖X‖)∥ · ÊTRE(‖X‖)·X
n<‖b
∑‖ bn·256‖b‖−1−n
(166) ÊTRE(X) ≡ (b0, b1, ...) :b06 = 0∧X=
n=0
(167) (un)·(avant JC)·(ré, é) = (un, b, c, ré, e)

AinsiÊTREest la fonction qui développe une valeur entière positive en un tableau d'octets gros-boutien de longueur minimale et l'opérateur
point effectue la concaténation de séquences.
Si au lieu de cela, la valeur à sérialiser est une séquence d'autres éléments, la sérialisation RLP prend l'une des deux formes suivantes :
• Si les sérialisations concaténées de chaque élément contenu ont une longueur inférieure à 56 octets, alors la sortie est égale à
cette concaténation préfixée par l'octet égal à la longueur de ce tableau d'octets plus 192.
• Sinon, la sortie est égale aux sérialisations concaténées préfixées par le tableau d'octets de longueur minimale qui, lorsqu'il est
interprété comme un entier gros boutien, est égal à la longueur du tableau d'octets de sérialisations concaténées, qui est lui-
même préfixé par le nombre d'octets requis pour coder fidèlement cette valeur de longueur plus 247.
Ainsi terminons-nous en définissant formellementRje:
{
(192 +‖s(X)‖)·s(X) ( si‖s(X)‖ <56
(168) Rje(X) ≡ ∥ ∥)
247 +∥ÊTRE(‖s(X)‖)∥ · ÊTRE(‖s(X)‖)·s(X) sinon
(169) s(X) ≡ RLP(X0)·RLP(X1)...
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 17

Si RLP est utilisé pour coder un scalaire, défini uniquement comme un entier positif (Pou n'importe lequelXpourPX), il doit être spécifié comme
le tableau d'octets le plus court de sorte que son interprétation gros-boutiste soit égale. Ainsi le RLP d'un entier positifjeest défini comme:

(170) RLP(je:je∈P)≡RLP(BE(je))
Lors de l'interprétation des données RLP, si un fragment attendu est décodé en tant que scalaire et que des zéros non significatifs sont trouvés dans la
séquence d'octets, les clients sont tenus de le considérer comme non canonique et de le traiter de la même manière que des données RLP autrement
invalides, en le rejetant complètement.
Il n'y a pas de format de codage canonique spécifique pour les valeurs signées ou à virgule flottante.

annexeCCodage de préfixe hexadécimal

Le codage par préfixe hexadécimal est une méthode efficace pour coder un nombre arbitraire de quartets sous la forme d'un tableau d'octets. Il est
capable de stocker un indicateur supplémentaire qui, lorsqu'il est utilisé dans le contexte du trie (le seul contexte dans lequel il est utilisé), lève l'ambiguïté
entre les types de nœuds.
Elle est définie comme la fonctionCVqui cartographie à partir d'une séquence de quartets (représentés par l'ensembleY)avec une
valeur booléenne à une séquence d'octets (représentée par l'ensembleB):

{
(16F(t),16X[0] +X[1],16X[2] +X[3], ...) si‖X‖est même
(171) CV(X, t) :X∈Oui ≡
(16(F(t) + 1) +X[0],16X[1] +X[2],16X[3] +X[4], ...) autrement
{
2 sit6 = 0
(172) F(t) ≡
0 sinon
Ainsi, le quartet haut du premier octet contient deux drapeaux ; le bit le plus bas codant l'impair de la longueur et le deuxième bit le plus bas
codant le drapeaut. Le quartet de poids faible du premier octet est nul dans le cas d'un nombre pair de quartets et le premier quartet dans le cas
d'un nombre impair. Tous les quartets restants (maintenant un nombre pair) s'intègrent correctement dans les octets restants.

annexeD.Arbre Merkle Patricia modifié

L'arbre Merkle Patricia modifié (trie) fournit une structure de données persistante à mapper entre des données binaires de longueur arbitraire
(tableaux d'octets). Il est défini en termes de structure de données mutable pour mapper entre des fragments binaires de 256 bits et des données
binaires de longueur arbitraire, généralement implémentées sous forme de base de données. Le cœur du trie, et sa seule exigence en termes de
spécification de protocole est de fournir une valeur unique qui identifie un ensemble donné de paires clé-valeur, qui peut être soit une séquence
de 32 octets, soit la séquence d'octets vides. Il est laissé comme considération de mise en œuvre de stocker et de maintenir la structure du trie
d'une manière qui permette une réalisation efficace et efficiente du protocole.
Formellement, nous supposons la valeur d'entréeJE,un ensemble contenant des paires de séquences d'octets :

(173) je ={(k0∈B,v0∈B),(k1∈B,v1∈B), ...}

Lorsque nous considérons une telle séquence, nous utilisons la notation commune en indice numérique pour faire référence à la clé ou à la valeur d'un tuple, ainsi :

(174) ∀je∈jeje≡(je0, JE1)

Toute série d'octets peut également être considérée de manière triviale comme une série de quartets, avec une notation spécifique endian ; ici, nous
supposons gros-boutien. Ainsi:

(175) y(JE) = {(k′ 0∈Oui,v0∈B),(k′ 1∈Oui,v1∈B), ...}

{
bkn[je÷2]÷16c kn[b sijeest même
(176) ∀n ∀je:je <2‖kn‖ k′n[je] ≡
je÷2c] mode 16 sinon
On définit la fonctionTRIÉ,qui évalue à la racine du trie qui représente cet ensemble lorsqu'il est encodé dans cette
structure :
(177) TRIE(JE)≡KEC(c(JE,0))

On suppose aussi une fonctionn, la fonction de limite de nœud du trie. Lors de la composition d'un nœud, nous utilisons RLP pour encoder la
structure. Afin de réduire la complexité du stockage, pour les nœuds dont le RLP composé est inférieur à 32 octets, nous stockons le RLP
directement ; pour les plus grands, nous affirmons la prescience du tableau d'octets dont le hachage Keccak s'évalue à notre référence.
Ainsi définissons-nous en termes dec, la fonction de composition de nœud :
-
-() si je =∅
(178) n(JE, je)≡ c(JE, je) si ‖c(JE, je)‖ <32
--
KEC(c(JE, je)) sinon
D'une manière similaire à un arbre de base, lorsque le trie est parcouru de la racine à la feuille, on peut construire une seule paire clé-valeur. La
clé est accumulée tout au long du parcours, en acquérant un seul quartet à partir de chaque nœud de branche (tout comme avec un arbre de
base). Contrairement à un arbre de base, dans le cas de plusieurs clés partageant le même préfixe ou dans le cas d'une seule clé ayant
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 18

un suffixe unique, deux nœuds d'optimisation sont fournis. Ainsi, lors de la traversée, on peut potentiellement acquérir plusieurs
quartets de chacun des deux autres types de nœuds, extension et feuille. Il existe trois types de nœuds dans le trie :
Feuille:Une structure à deux éléments dont le premier élément correspond aux quartets dans la clé non déjà pris en compte par le
accumulation de clés et de branches parcourues depuis la racine. La méthode de codage par préfixe hexadécimal est utilisée et
le deuxième paramètre de la fonction doit êtrevrai.
Extension:Une structure à deux éléments dont le premier élément correspond à une série de quartets de taille supérieure à un qui
sont partagées par au moins deux clés distinctes au-delà de l'accumulation de clés de quartets et de branches traversées à
partir de la racine. La méthode de codage par préfixe hexadécimal est utilisée et le deuxième paramètre de la fonction doit être
FAUX.
Bifurquer:Une structure de 17 éléments dont les seize premiers éléments correspondent à chacune des seize valeurs de quartet possibles pour
les clés à ce stade de leur parcours. Le 17e élément est utilisé dans le cas où il s'agit d'un nœud de terminaison et donc
d'une clé se terminant à ce stade de sa traversée.
Une branche n'est alors utilisée qu'en cas de nécessité ; aucun nœud de branche ne peut exister qui ne contienne qu'une seule entrée non nulle. Nous
pouvons définir formellement cette structure avec la fonction de composition structurellec:
(179) ))
- ((
-
-RLP CV(je0[je.. (‖je0‖−1)], vrai), JE1 si ‖je‖=1 où∃je:je∈je
- (( ))
--RPP HP(je0[je..(j-1)], FAUX), n(JE, j) ( si je6
=j oùj=arg maxX:∃l :‖je‖=X:∀je∈je:je0[0..(x−1)] =je
)
c(JE, je)≡ -RLP (tu(0), tu(1), ..., tu(15), v) sinon oùtu(j) ≡ n
{({JE:je∈je∧je0[je] =j}, je+1)
-
- je1 si∃je:je∈je∧‖je0‖=je
-- v =
() sinon

D.1.Essayez la base de données.Ainsi, aucune hypothèse explicite n'est faite concernant les données stockées et celles qui ne le sont pas, car il
s'agit d'une considération spécifique à la mise en œuvre ; nous définissons simplement la fonction d'identité mappant l'ensemble clé-valeurje à un
hachage de 32 octets et affirmer qu'un seul de ces hachages existe pour toutJE,qui, bien que non strictement vrai, est précis avec une précision
acceptable compte tenu de la résistance aux collisions du hachage Keccak. En réalité, une implémentation sensée ne recalculera pas entièrement
le hachage de racine de trie pour chaque ensemble.
Une implémentation raisonnable maintiendra une base de données de nœuds déterminée à partir du calcul de divers essais ou, plus
formellement, elle mémorisera la fonctionc. Cette stratégie utilise la nature du trie à la fois pour rappeler facilement le contenu de tout ensemble
de valeurs-clés précédent et pour stocker plusieurs de ces ensembles de manière très efficace. En raison de la relation de dépendance, les preuves
de Merkle peuvent être construites avec unO(enregistrerN) l'exigence d'espace qui peut démontrer qu'une feuille particulière doit exister dans un
trie d'un hachage racine donné.

annexeE.Contrats précompilés
Pour chaque contrat précompilé, nous utilisons une fonction modèle, ΞPRÉ, qui implémente la vérification du manque de gaz.
{
(∅,0,UN0,()) (σ, g sig < gr
(180) ΞPRÉ(σ, g, je)≡
− gr,UN0,o) sinon

Les contrats précompilés utilisent chacun ces définitions et fournissent des spécifications pour leso (les données de sortie) etgr, les
besoins en gaz.
Pour la courbe elliptique DSA récupérer la fonction d'exécution de VM, nous définissons égalementdêtre les données d'entrée, bien définies
pour une longueur infinie en ajoutant des zéros si nécessaire. Surtout dans le cas d'une signature invalide (ECDSARECOVER(h, v, r, s) = ∅),alors
nous n'avons pas de sortie.

(181) ΞECREC ≡ΞPRÉ où:

(182) gr = 3000
{
0 siECDSARECOVER(h, v, r, s) =∅
(183) |o| =
32 sinon
(184) si |o|=32 :
(185) o[0..11] = 0
( )
(186) o[12..31] = KEC ECDSARECOVER(h, v, r, s) [12..31] jed où:
(187) d[0..(|jed|−1)] =
(188) d[|jed|..] = (0,0, ...)
(189) h = d[0..31]
(190) v = d[32..63]
(191) r = d[64..95]
(192) s = d[96..127]
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 19

Les deux fonctions de hachage, RIPEMD-160 et SHA2-256 sont plus trivialement définies comme une opération presque pass-through. Leur
consommation de gaz dépend de la taille des données d'entrée, un facteur arrondi au nombre de mots le plus proche.

(193) ΞSHA256 ≡ΞPRÉ où:

⌈|jed|⌉
(194) gr = 60 + 12
32
(195) o[0..31] = SHA256(jed)
(196) ΞRIP160 ≡ΞPRÉ où:
⌈|jed|⌉
(197) gr = 600 + 120
32
(198) o[0..11] = 0
(199) o[12..31] = RIPEMD160(jed)
(200)
Pour les besoins ici, nous supposons que nous avons des fonctions cryptographiques standard bien définies pour RIPEMD-160 et SHA2-256 de
la forme :

(201) SHA256(je∈B) ≡ o∈B32

(202) RIPEMD160(je∈B) ≡ o∈B20
Enfin, le quatrième contrat, la fonction identité ΞIDENTIFIANTdéfinit simplement la sortie comme l'entrée :

(203) ΞIDENTIFIANT ≡ΞPRÉ où:

⌈|jed|⌉
(204) gr = 15 + 3
32
(205) o = jed

annexeF.Signature de transactions
La méthode de signature des transactions est similaire aux « signatures de style Electrum » ; il utilise la courbe SECP-256k1 comme
décrit par Gura et al. [2004].
On suppose que l'expéditeur a une clé privée validepr, qui est un entier positif sélectionné au hasard (représenté par un tableau
d'octets de longueur 32 sous forme gros-boutiste) dans la plage [1,secp256k1n−1].
Nous affirmons les fonctionsECDSASIGN, ECDSARESTOREetECDSAPUBKEY.Celles-ci sont formellement définies dans la littérature.

(206) ECDSAPUBKEY(pr∈B32) ≡ ptu∈B64

(207) ECDSASIGN(e∈B32, pr∈B32) ≡ (v∈B1, r∈B32, s∈B32) ptu∈B
(208) ECDSARECOVER(e∈B32, v∈B1, r∈B32, s∈B32) ≡ 64

Oùptuest la clé publique, supposée être un tableau d'octets de taille 64 (formé de la concaténation de deux entiers positifs chacun<2
256) etprest la clé privée, un tableau d'octets de taille 32 (ou un seul entier positif dans la plage susmentionnée). Il est entendu quevest
'l'identifiant de récupération', une valeur de 1 octet spécifiant le signe et la finitude du point de la courbe ; cette valeur est dans la gamme
de [27,30], cependant nous déclarons les deux possibilités supérieures, représentant des valeurs infinies, invalides.
Nous déclarons qu'une signature est invalide à moins que toutes les conditions suivantes ne soient remplies :

(209) 0<r <secp256k1n

{
secp256k1n siHje<NH
(210) 0<s <
secp256k1n÷2 sinon
(211) v∈ {27,28}
où:
(212) secp256k1n =115792089237316195423570985008687907852837564279074904382605163141518161494337
Pour une clé privée donnée,pr, l'adresse EthereumUN(pr) (une valeur de 160 bits) à laquelle il correspond est défini comme le
les 160 bits les plus à droite du hachage Keccak de la clé publique ECDSA correspondante :
(( ))
(213) UN(pr) =B96..255KEC ECDSAPUBKEY(pr)
Le hachage du message,h(J), à signer est le hachage Keccak de la transaction sans les trois derniers composants de
signature, formellement décrits commeJr,JsetJw:
{
(Jn, Tp, Tg, Tt, Tv , Tje) siJt=0
(214) LS(J) ≡
(Jn, Tp, Tg, Tt, Tv, Td) sinon
(215) h(J) ≡ KEC(LS(J))
La transaction signéeg(T, pr) est défini comme:
(216) g(T, pr)≡Jsauf:
(217) (Jw, Tr, Ts) =ECDSASIGN(h(J), pr)
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 20

Nous pouvons alors définir la fonction d'expéditeurSde la transaction en tant que :

(( ))
(218) S(J)≡B96..255KEC ECDSARECOVER(h(J), Tw, Tr, Ts)

L'assertion selon laquelle l'expéditeur d'une transaction signée est égale à l'adresse du signataire devrait être évidente :

(219) ∀J:∀pr:S(g(T, pr))≡UN(pr)

annexeG.Barème des frais

La grille tarifairegest un tuple de 31 valeurs scalaires correspondant aux coûts relatifs, en gaz, d'un certain nombre d'opérations
abstraites qu'une transaction peut effectuer.
Nom Valeur Description*

gzéro 0 Rien payé pour les opérations de l'ensembleOzéro. Quantité de gaz à

gbase 2 payer pour les opérations de l'ensembleObase. Quantité de gaz à payer
gtrès lent 3 pour les opérations de l'ensembleOtrès lent. Quantité de gaz à payer
gfaible 5 pour les opérations de l'ensembleOfaible. Quantité de gaz à payer pour
gmilieu 8 les opérations de l'ensembleOmilieu. Quantité de gaz à payer pour les
ghaut dix opérations de l'ensembleOhaut. Quantité de gaz à payer pour les
gcode_ext 700 opérations de l'ensembleOcode_ext. Quantité d'essence à payer pour un
géquilibre 400 ÉQUILIBREopération. Payé pour unSLOADopération. Payé pour un

gcharge 200 JUMPDESTopération.

gjumpdest 1
gsset 20000 Payé pour unSTOREopération lorsque la valeur de stockage est définie sur une valeur différente de zéro à partir de zéro.

gsréinitialiser 5000 Payé pour unSTOREopération lorsque le zéro de la valeur de stockage reste inchangé ou est mis à zéro. Remboursement accordé
Rclair 15000 (ajouté au compteur de remboursement) lorsque la valeur de stockage est définie sur zéro à partir de non-zéro. Remboursement
Rsuicide 24000 accordé (ajouté au compteur de remboursement) pour avoir suicidé un compte.
gsuicide 5000 Quantité d'essence à payer pour unSUICIDEopération.
gcréer 32000 Payé pour unCRÉERopération.
gdépôt de code 200 Payé par octet pour unCRÉERopération pour réussir à placer le code dans l'état.
gappel 700 Payé pour unAPPELopération.
gvaleur d'appel 9000 Payé pour un transfert de valeur non nulle dans le cadre duAPPELopération.
gallocation d'appel 2300 Une allocation pour le contrat appelé soustraite degvaleur d'appelpour un transfert de valeur non
gnouveau compte 25000 nulle. Payé pour unAPPELouSUICIDEopération qui crée un compte. Paiement partiel d'unEXP
gexp dix opération.
gexpbyte dix Paiement partiel multiplié pardenregistrer256(exposant)epour leEXPopération. Payé pour
gmémoire 3 chaque mot supplémentaire lors de l'extension de la mémoire.
gtxcreate 32000 Payé par toutes les transactions créant un contrat après laTransition de la ferme. Payé
gtxdatazero 4 pour chaque zéro octet de données ou de code pour une transaction.
gtxdatanonzero 68 Payé pour chaque octet de données ou de code différent de zéro pour une transaction.
gtransaction 21000 Payé pour chaque transaction.

genregistrer 375 Paiement partiel d'unENREGISTRERopération. Payé pour chaque

glogdata 8 octet dans unENREGISTRERles données de l'opération. Payé pour
gsujet de journal 375 chaque sujet d'unENREGISTRERopération. Payé pour chaqueSHA3
gsha3 30 opération.
gsha3mot 6 Payé pour chaque mot (arrondi) pour les données d'entrée d'unSHA3opération. Paiement
gcopie 3 partiel pour *COPIEopérations, multipliées par les mots copiés, arrondies. Paiement pour
gbloc de hachage 20 BLOCHASHopération.

annexeHSpécification de la machine virtuelle

Lors de l'interprétation de valeurs binaires 256 bits comme des entiers, la représentation est big-endian.
Lorsqu'une donnée machine 256 bits est convertie vers et à partir d'une adresse ou d'un hachage 160 bits, les 20 octets vers la droite (de poids faible pour
BE) sont utilisés et les 12 octets les plus à gauche sont ignorés ou remplis de zéros, ainsi les valeurs entières ( lorsque les octets sont interprétés comme gros
boutiens) sont équivalentes.

H.1.Coût du gaz.La fonction de coût général du gaz,C, est défini comme:

 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 21

(220) -
-C STORE(σ,µ) si w= STORE
-
--gexp si w=EXP∧ µs[1] = 0 w=
-
-g exp + gexpbyte×(1 + b 256(µs[1])c ) si EXP∧ µs[1]>0
-
enregistrer

--gtrès lent+gcopie×dµs[2]÷32e si w=CALLDATACOPY∨CODECOPIE

-
-g code_ext+ gcopie×dµs[3]÷32e si w=EXTCODECOPIE
-
--genregistrer+glogdata× µs[1] si w=LOG0
- si w=LOG1
-g enregistrer+glogdata× µs[ 1] +gsujet de journal
-
--genregistrer+glogdata× µs[1] + 2gsujet de journal si w=LOG2
- si w=LOG3
-g
-enregistrer+glogdata× µs[1] + 3gsujet de journal
-g enregistrer+glogdata× µs[1] + 4gsujet de journal si w=LOG4
-
--CAPPEL(σ,µ) si w=APPEL∨CODE D'APPEL∨APPEL DÉLÉGUÉ
-
-CSUICIDE(σ,µ) si w=SUICIDE
C(σ,µ,je)≡Cmem(µ′ je)−Cmem(µje)+ si w=CRÉER
- gcréer
--gsha3+gsha3motds[1]÷32e si w=SHA3
-
-g jumpdest si w=JUMPDEST
-
--gcharge si w=SLOAD
- si w∈Ozéro
-g zéro
-
--gbase si w∈Obase
- si w∈Otrès lent
-gtrès lent
-
-g faible si w∈Ofaible
-
--gmilieu si w∈Omilieu
-
-g haut si w∈Ohaut
-
--gcode_ext si w∈Ocode_ext
-
g
-équilibre si w=ÉQUILIBRE
-gbloc de hachage
si w=BLOCHASH
{
jeb[µpc] siµpc<‖jeb‖
(221) w≡
ARRÊT sinon
où:
⌊un2⌋
(222) Cmem(un)≡gmémoire·un+
512
avecCAPPEL,CSUICIDEetCSTOREtel que spécifié dans la section appropriée ci-dessous. Nous définissons les sous-ensembles d'instructions
suivants :
Ozéro={ARRÊTER, RETOUR}
Obase={ADRESSE, ORIGINE, APPELANT, CALLVALUE, CALLDATASIZE, CODESIZE, GASPRICE, COINBASE,
HORODATAGE, NOMBRE, DIFFICULTÉ, GASLIMIT, POP, PC, MSIZE, GAS}
Otrès lent={ADD, SUB, NOT, LT, GT, SLT, SGT, EQ, ISZERO, AND, OR, XOR, BYTE, CALLDATALOAD,
MLOAD, MSTORE, MSTORE8, PUSH*, DUP*, SWAP*} Ofaible={
MUL, DIV, SDIV, MOD, SMOD, SIGNEXTEND} Omilieu={ADDMOD,
MULMOD, JUMP} Ohaut={JUMPI} Ocode_ext={EXTCODETAILLE}

Notez le composant de coût de la mémoire, donné comme le produit degmémoireet le maximum de 0 & le plafond du nombre de mots
en taille que la mémoire doit avoir sur le nombre de mots courant,µjeafin que tous les accès référencent une mémoire valide que ce soit
en lecture ou en écriture. Ces accès doivent être pour un nombre d'octets non nul.
Référencer une plage de longueur nulle (par exemple en essayant de la transmettre comme plage d'entrée à un CALL) ne nécessite pas de mémoire
à étendre jusqu'au début de la gamme.µ′ jeest défini comme ce nouveau nombre maximum de mots de mémoire active ;
des cas particuliers sont donnés où ces deux ne sont pas égaux.
Notez également queCmemest la fonction de coût mémoire (la fonction d'expansion étant la différence entre le coût avant et
après). C'est un polynôme, avec le coefficient d'ordre supérieur divisé et plancher, et donc linéaire jusqu'à 724B de mémoire
utilisée, après quoi il coûte beaucoup plus cher.
Lors de la définition du jeu d'instructions, nous avons défini l'extension de mémoire pour la fonction de plage,M, ainsi:

{
s sije=0
(223) M(s, f, l)≡
max(s,d(F+je)÷32e) sinon
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 22

Une autre fonction utile est la fonction "tous sauf un 64ème"Ldéfini comme:

(224) L(n)≡n− bn/64c

H.2.Jeu d'instructions.Comme précisé précédemment dans la section 9, ces définitions prennent place dans le contexte final ici.
En particulier nous supposonsOest la fonction de progression d'état EVM et définit les termes relatifs à l'état du cycle suivant (σ′
,µ′) tel que:

(225) O(σ,µ,un, je)≡(σ′,µ′,UN′, JE) avec des exceptions, comme indiqué

Voici les diverses exceptions aux règles de transition d'état données à la section 9 spécifiées pour chaque instruction, ainsi que les
définitions supplémentaires spécifiques à l'instruction deJetC. Pour chaque instruction, est également spécifiéα, les éléments
supplémentaires placés sur la pile etδ, les éléments retirés de la pile, tels que définis à la section 9.
0s : Opérations d'arrêt et arithmétiques
Toute arithmétique est modulo 2256sauf indication contraire.

Valeur Mnémonique δ α Description

0x00 ARRÊT 0 0 Arrête l'exécution.

0x01 AJOUTER 2 1 Opération d'addition.

µ′s[0]≡µs[0] +µs[1]
0x02 MUL 2 1 Opération de multiplication.
µ′s[0]≡µs[0]× µs[1]
0x03 SOUS 2 1 Opération de soustraction.
µ′s[0]≡µs[0]− µs[1]
0x04 DIV 2 1 Opération de division entière.
0 siµs[1] = 0
µ′s[0]≡
bµs[0]÷ µs[1]c sinon
0x05 SDIV 2 1 Connecté-opération de division en teger (tronquée).
-0 si µs[1] = 0
µ′s[0]≡ -2255 si µ[0]
s =−2255∧µs[1] =−1 sinon
--
sgn(µs[0]÷ µs[1])b|µs[0]÷ µs[1]|c
Où toutes les valeurs sont traitées comme des entiers 256 bits signés en complément à deux.
Notez la sémantique de débordement lorsque−2255est nié.

0x06 MOD 2 1 Modulo{opération de reste.

0 si µs[1] = 0
µ′s[0]≡
µs[0] moduleµs[1] sinon
0x07 SMOD 2 1 Signé m{opération de reste odulo.
0 siµs[1] = 0
µ′s[0]≡
sgn(µs[0])|µs[0]|mode|µs[1]| sinon
Où toutes les valeurs sont traitées comme des entiers 256 bits signés en complément à deux.

0x08 ADDMOD 3 1 Modulo{opération d'addition.

0 siµs[2] = 0
µ′s[0]≡
(µs[0] +µs[1]) modeµs[2] sinon
Tous les calculs intermédiaires de cette opération ne sont pas soumis au 2256modulo.
0x09 MULMOD 3 1 Modulo{opération de multiplication.
0 siµs[2] = 0
µ′s[0]≡
(µs[0]× µs[1]) modeµs[2] sinon
Tous les calculs intermédiaires de cette opération ne sont pas soumis au 2256modulo.
0x0a EXP 2 1 Opération exponentielle.
µ′s[0]≡µs[0]µs[1]
0x0bSIGNEXTEND2 1 Prolonge la longueur d'un entier signé complémentaire à deux.
µs[1] t sije6toùt=256−8(µs[0] + 1) sinon
∀je∈[0..255] :µ′[0
s]je≡
µs[1]je
µs[X]jedonne lejeème bit (en partant de zéro) deµs[X]
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 23

10s : Comparaison et opérations logiques au niveau des bits

Valeur Mnémoniqueδ αDescription
0x10 LT 2 1 Moins-tha{
n comparaison.
1 siµs[0]<µs[1]
µ′s[0]≡
0 sinon
0x11 GT 2 1 que la comparaison.
Plus grand-{
1 siµs[0]>µs[1]
µ′s[0]≡
0 sinon
0x12 SLT 2 1 Comparaison moins-que signée.
1 siµs[0]<µs[1]
µ′s[0]≡
0 sinon
Où toutes les valeurs sont traitées comme des entiers 256 bits signés en complément à deux.

0x13 SGT 2 1 Signé g{ plus grande que la comparaison.

1 siµs[0]>µs[1]
µ′s[0]≡
0 sinon
Où toutes les valeurs sont traitées comme des entiers 256 bits signés en complément à deux.

0x14 égaliseur 2 1 Égalité{comparaison.

1 siµs[0] =µs[1]
µ′s[0]≡
0 sinon
0x15 EST ZÉRO 1 1 Opérateur n{ot simple.
1 siµs[0] = 0
µ′s[0]≡
0 sinon
0x16 ET 2 1 Opération ET au niveau du bit.
∀je∈[0..255] :µ′ s[0]je≡µs[0]je∧ µs[1]je
0x17 OU 2 1 Opération OU au niveau du bit.
∀je∈[0..255] :µ′ s[0]je≡µs[0]je∨ µs[1]je
0x18 XOR 2 1 Opération XOR au niveau du bit.
∀je∈[0..255] :µ′ s[0]je≡µs[0]je⊕ µs[1]je
0x19 PAS 1 1 Opération NOT au niveau du bit {.

1 siµs[0]je=0
∀je∈[0..255] :µ′ s[0]je≡
0 sinon
0x1a OCTET 2 1 Récupérer un seul octet de{ m mot.
µs[1](je+8µs[0]) sije <8∧ µs[0]<32
∀je∈[0..255] :µ′ s[0]je≡
0 sinon
Pour le Nième octet, on compte à partir de la gauche (c'est-à-dire que N=0 serait le plus significatif en big endian).

20s : SHA3
Valeur Mnémoniqueδ αDescription
0x20SHA3 21 Calculez le hachage Keccak-256.
µ′s[0]≡Keccak(µm[µs[0]. . .(µs[0] +µs[1]−1)])
µ′je≡M(µje,µs[0],µs[1])
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 24

30s : Description des informations

Valeur Mnémonique δ α environnementales

0x30 ADRESSE 0 1 Obtenir l'adresse du compte en cours d'exécution.

µ′s[0]≡jeun
0x31 ÉQUILIBRE 1 1 Obtenez bala{nce du compte donné.
′ σ[µs[0]] b siσ[µs[0] mod 2160]6 =∅
s[≡
µ0]
0 sinon
0x32 ORIGINE 0 1 Obtenir l'adresse d'origine de l'exécution.
µ′s[0]≡jeo
Il s'agit de l'expéditeur de la transaction d'origine ; il ne s'agit jamais d'un compte avec un code
associé non vide.

0x33 VOTRE INTERLOCUTEUR 0 1 Obtenir l'adresse de l'appelant.

µ′s[0]≡jes
Il s'agit de l'adresse du compte qui est directement responsable de cette exécution.
0x34 CALLVALUE 0 1 Obtenir la valeur déposée par l'instruction/transaction responsable de cette exécution.
µ′s[0]≡jev
0x35CALLDATALOAD1 1 Obtenir les données d'entrée de l'environnement actuel.
µ′s[0]≡jed[µs[0]. . .(µs[0] + 31)] avecjed[X] = 0 siX>‖jed‖
Cela concerne les données d'entrée transmises avec l'instruction ou la transaction d'appel de message.

0x36CALLDATASIZE 0 1 Obtenir la taille des données d'entrée dans l'environnement actuel.

µ′s[0]≡ ‖jed‖
Cela concerne les données d'entrée transmises avec l'instruction ou la transaction d'appel de message.

0x37CALLDATACOPY3 0 Copier les données d'entrée dans l'environnement actuel vers la mémoire.
jed[µs[1] +je] siµs[1] +je <‖jed‖
∀je∈{0...µs[2]−1}µ′ µ
m[ s[0] +je]≡
0 sinon
µ′je≡M(µje,µs[0],µs[2])
Cela concerne les données d'entrée transmises avec l'instruction ou la transaction d'appel de message.

0x38 CODETAILLE 0 1 Obtenir la taille du code exécuté dans l'environnement actuel.

µ′s[0]≡ ‖jeb‖
0x39 CODECOPIE 3 0 Copiez le code en cours d'exécution dans l'environnement actuel vers la mémoire.

jeb[µs[1] +je] siµs[1] +je <‖jeb‖

∀je∈{0...µs[2]−1}µ′ µ
m[ s[0] +je]≡
ARRÊT sinon
µ′je≡M(µje,µs[0],µs[1])
0x3a PRIX DE L'ESSENCE 0 1 Obtenez le prix du gaz dans l'environnement actuel.
µ′s[0]≡jep
Il s'agit du prix du gaz spécifié par la transaction d'origine.
0x3b EXTCODETAILLE 1 1 Obtenir la taille du code d'un compte.
µ′s[0]≡ ‖σ[µs[0] mod 2160]c‖
0x3c EXTCODECOPIE 4 0 {ory.
Copier le code d'un compte dans mem
c[µs[2] +je] siµs[2] +je <‖c‖
∀je∈{0...µs[3]−1}µ′ µ
m[ s[1] +je]≡
ARRÊT sinon
oùc≡σ[µs[0] mod 2160]c
µ′je≡M(µje,µs[1],µs[3])
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 25

40s : informations sur le bloc

Valeur Mnémonique δ αDescription

0x40BLOCHASH1 1 Obtenez le hachage de l'un des 256 blocs complets les plus récents.
µ′s[0]≡P(jeHp,µs[0],0)
oùPest le hachage d'un bloc d'un nombre particulier, jusqu'à un âge maximum.
0 est laissé sur la pile si le numéro de bloc recherché est supérieur au numéro de bloc actuel
ou supérieur à -256 blocs derrière le bloc actuel.
-0 si n > Hje∨un=256∨h=0 n=H
P(h, n, une)≡h si je
--
P(Hp, n / A+1) sinon
et nous affirmons l'en-têteHpeut être déterminé car son hachage est le hachage parent
dans le bloc qui le suit.

0x41COINBASE 0 1 Obtenir l'adresse du bénéficiaire du bloc.

µ′s[0]≡jeHc
0x42HORODATAGE 0 1 Récupère l'horodatage du bloc.
µ′s[0]≡jeHs
0x43NOMBRE 0 1 Obtenir le numéro du bloc.
µ′s[0]≡jeSalut
0x44DIFFICULTÉ 0 1 Obtenez la difficulté du bloc.
µ′s[0]≡jeHD
0x45LIMITE DE GAZ 0 1 Obtenez la limite de gaz du bloc.
µ′s[0]≡jeHl
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 26

50s : Opérations de pile, de mémoire, de stockage et de flux

Valeur Mnémoniqueδ αDescription
0x50 POPULAIRE 1 0 Supprimer l'élément de la pile.

0x51 MLOAD 1 1 Charger le mot de la mémoire.

µ′s[0]≡µm[µs[0]. . .(µs[0] + 31)]
µ′je≡max(µje,d(µs[0] + 32)÷32e)
L'ajout dans le calcul deµ′ jen'est pas soumis au 2256modulo.
0x52 MSTORE 2 0 Enregistrer le mot dans la mémoire.

µ′m[µs[0]. . .(µs[0] + 31)]≡µs[1]

µ′je≡max(µje,d(µs[0] + 32)÷32e)
L'ajout dans le calcul deµ′ jen'est pas soumis au 2256modulo.
0x53 MSTORE8 2 0 Enregistrer l'octet en mémoire.
µ′m[µs[0]]≡(µs[1] mod 256)
µ′je≡max(µje,d(µs[0] + 1)÷32e)
L'ajout dans le calcul deµ′ jen'est pas soumis au 2256modulo.
0x54 SLOAD 1 1 Charger le mot du stockage.
µ′s[0]≡σ[jeun]s[µs[0]]
0x55 STORE 2 0 Enregistrer le mot dans le
stockage. σ′[jeun]s[µs[0]]≡µs{[1]

gsset siµs[1]6 = 0∧σ[jeun]s[µs[0]] = 0

CSTORE(σ,µ)≡
gsréinitialiser sinon
{
Rclair siµs[1] = 0∧σ[jeun]s[µs[0]]6 =0
UN
r≡UN
′ r+
0 sinon
0x56 SAUT 1 0 Modifier le compteur de
programme. JSAUT(µ)≡µs[0]
Cela a pour effet d'écrire ladite valeur àµpc. Voir rubrique 9.
0x57 JUMPI 2 0 Modifiez{conditionnellement le compteur de programme.

µs[0] siµs[1]6 = 0
JJUMPI(µ)≡
µpc+1 sinon
Cela a pour effet d'écrire ladite valeur àµpc. Voir rubrique 9.
0x58 PC 0 1 Obtenir la valeur du compteur de programmeavantà l'incrément
correspondant à cette instruction.
µ′s[0]≡µpc
0x59 MSIZE 0 1 Obtenir la taille de la mémoire active en octets.
µ′s[0]≡32µje
0x5a GAZ 0 1 Obtenez la quantité de gaz disponible, y compris la réduction correspondante
pour le coût de cette instruction.
µ′s[0]≡µg
0x5bJUMPDEST 0 0 Marquez une destination valide pour les sauts.
Cette opération n'a aucun effet sur l'état de la machine pendant l'exécution.
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 27

Années 60 et années 70 : opérations de poussée

Valeur Mnémoniqueδ αDescription

0x60 PUSH1 0 1 Place un élément de 1 octet sur la pile.
µ′s[0]≡c(µpc+{1)
jeb[x] six <‖jeb‖
oùc(X)≡
0 sinon
Les octets sont lus en ligne à partir du tableau d'octets du code du programme.
La fonctioncgarantit que les octets sont par défaut à zéro s'ils dépassent les limites.
L'octet est aligné à droite (il prend la place la plus basse en big endian).
0x61 PUSH2 0 1 Placez l'élément 2-b(yte sur la pile.
)
µ′s[0]≡c(µpc+1). . .(µpc+2)
avecc(X)≡(c(X0), ..., c(X‖X‖−1)) avecctel que défini ci-dessus.
Les octets sont alignés à droite (ils prennent la place la plus basse en big endian).

... ...
.. .. .. ...

0x7f PUSH32 01 Lieu 32-b (yte (mot complet) élément sur)pile.

µ′s[0]≡c(µpc+1). . .(µpc+32)
oùcest défini comme ci-dessus.
Les octets sont alignés à droite (ils prennent la place la plus basse en big endian).

Années 80 : Mnémonique des opérations

Valeur de duplication δ α Description

0x80 DUP1 1 2 Dupliquer le 1er élément de la pile.
µ′s[0]≡µs[0]
0x81 DUP2 2 3 Dupliquer l'élément de la 2e pile.
µ′s[0]≡µs[1]

... ...
.. . . . . ...

0x8f DUP16 16 17 Dupliquer le 16ème élément de la pile.

µ′s[0]≡µs[15]
Années 90 : Mnémonique des

Valeur opérations d'échangeδ α Description

0x90 SWAP1 2 2 Échangez les objets de la 1ère et de la 2ème pile.
µ′s[0]≡µs[1]
µ′s[1]≡µs[0]
0x91 SWAP2 3 3 Échangez les objets de la 1ère et de la 3ème pile.
µ′s[0]≡µs[2]
µ′s[2]≡µs[0]

... ...
.. .. .. ...

0x9f SWAP16 17 17 Échangez les objets de la 1ère et de la 17ème pile.

µ′s[0]≡µs[16]
µ′s[16]≡µs[0]
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 28

a0s : Opérations de journalisation

Pour toutes les opérations de journalisation, le changement d'état consiste à ajouter une entrée de journal supplémentaire à la série de journaux du sous-état :
UN
je≡UN
′ je·(jeun,t,µm[µs[0]. . .(µs[0] +µs[1]−1)])
La série de sujets de l'entrée,t,diffère en

conséquence : Valeur Mnémoniqueδ αDescription

0xa0 LOG0 2 0 Ajouter un enregistrement de journal sans rubriques.

t≡()

0xa1 LOG1 3 0 Ajouter un enregistrement de journal avec un

sujet. t≡(µs[2])

... ...
.. . . . . ...

0xa4 LOG4 6 0 Ajouter un enregistrement de journal avec

quatre sujets. t≡(µs[2],µs[3],µs[4],µs[5])
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 29

f0s : opérations système

Valeur Mnémoniqueδ αDescription
0xf0 CRÉER 3 1 Créez un nouveau compte avec le code associé.
je≡µm[µs[1]. .{ . (µs[1] +µs[2]−1)]
Λ(σ∗, JEun, JEo,L(µg), JEp,µs[0],je, JEe+1) ( si µs[0]6σ[jeun]b∧jee<1024
(σ′,µ′ g,UN+) ≡ )
σ,µg,∅ sinon
σ∗≡σ sauf σ∗[jeun]n=σ[jeun]n+1
UN′≡UN d UN+ce qui implique:UN′ s≡UNs∪ UN+s ∧UN′ je≡UNje·UNje+ ∧UN′ r≡UNr+UN+ r
µ′s[0]≡X
oùX=0 si l'exécution du code pour cette opération a échoué à cause d'un arrêt
exceptionnel Z(σ∗,µ,je) =>oujee=1024
(la limite de profondeur d'appel maximale est atteinte) ouµs[0]> σ[jeun]b(le solde de l'appelant est trop
faible pour effectuer le transfert de valeur ); et sinonX=UN(jeun,σ[jeun]n), l'adresse du nouveau
compte créé, sinon.
µ′je≡M(µje,µs[1],µs[2])
Ainsi, l'ordre des opérandes est : valeur, décalage d'entrée, taille d'entrée.

0xf1 APPEL 7 1 Message-appel dans un

µ.s[3]
compte. je≡µm[µs[3] . .(-+µs[4]−1)]
- Θ(σ, jeun, JEo, t, t, siµs[2]6σ[jeun]b∧
(σ′, g′,UN+,o)≡ CCALGAS(µ), JEp,µs[2],µs[2],je, JEe+1) jee<1024
--
(σ, g,∅,o) sinon
n≡min({µs[6], |o|})
µ′m[µs[5]. . .(µs[5] +n−1)] =o[0. . .(n−1)]
µ′g≡µg+g′
µ′s[0]≡X
UN′≡UN d UN+
t≡µs[1] mode 2160
oùX=0 si l'exécution du code pour cette opération a échoué à cause d'un arrêt exceptionnel Z(
σ,µ,je) =>ou si
µs[2]> σ[jeun]b(pas assez de fonds) oujee=1024 (limite de profondeur d'appel atteinte) ;X=1
sinon.
µ′je≡M(M(µje,µs[3],µs[4]),µs[5],µs[6])
Ainsi l'ordre des opérandes est : gaz, à, valeur, en décalage, en taille, en décalage, en
taille. CAPPEL(σ,µ)≡CGéorgie{SCAP(σ,µ) +CSUPPLÉMENTAIRE(σ,µ)
CGASCAP(σ,µ) +gallocation d'appel siµs[2]6 = 0
C CALGAS(σ,µ)≡
CGASCAP(σ,µ) sinon
{
min{L(µg− CSUPPLÉMENTAIRE(σ,µ)),µs[0]} siµg≥CSUPPLÉMENTAIRE(σ,µ)
C GASCAP(σ,µ)≡
µs[0] sinon
) ≡gappel+CXFER(µ) +CNOUVEAU(σ,µ)
CSUPPLÉMENTAIRE(σ,
gvaleur d'appel siµs[2]6 = 0
µ{ CXFER(µ)≡
0 sinon
{
gnouveau compte siσ[µs[1] mode 2160] =∅
CNOUVEAU(σ,µ)≡
0 sinon
0xf2CODE D'APPEL 7 1 Message-appel sur ce compte avec un autre code de compte.
Exactement équivalent-t àAPPELsauf:
-- Θ(σ∗, JEun, JEo, JEun, t, si µs[2]6σ[jeun]b∧ je
(σ′, g′,UN+,o)≡ CCALGAS(µ), JEp,µs[2],µs[2],je, JEe+1) e<1024
--
(σ, g,∅,o) sinon
Notez le changement du quatrième paramètre à l'appel Θ à partir de la 2ème valeur de pileµs[1]
(comme dansAPPEL)à l'adresse actuellejeun. Cela signifie que le destinataire est en fait le même
compte qu'actuellement, simplement que le code est écrasé.

0xf3RETOUR 2 0 Arrête l'exécution renvoyant les données de sortie.

HRETOUR(µ)≡µm[µs[0]. . .(µs[0] +µs[1]−1)]
Cela a pour effet d'arrêter l'exécution à ce point avec la sortie définie.
Voir rubrique 9.
µ′je≡M(µje,µs[0],µs[1])
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 30

0xf4APPEL DÉLÉGUÉ6 1 Message-appel dans ce compte avec un autre code de compte, mais persistant
les valeurs actuelles deexpéditeuretvaleur.
Comparé àAPPEL, DÉLÉGUÉAPPELprend un argument de moins. L'argument omis estµs
[2]. Par conséquent,µs[3],µs[4],µs[5] etµs[6] dans la définition deAPPEL
doivent respectivement être remplacés parµs[2],µs[3],µs[4] etµs[5].
Sinon exactement-y équivalent àAPPELsauf:
- Θ(σ∗, JEs, JEo, JEun, t,
sijev6σ[jeun]b∧jee<1024
(σ′, g′,UN+,o)≡ µs[0], JEp,0, JEv,je, JEe+1)
--
(σ, g,∅,o) sinon
Notez les modifications (en plus de celle du quatrième paramètre) des deuxième et
neuvième paramètres de l'appel Θ.
Cela signifie que le destinataire est en fait le même compte qu'actuellement, simplement
que le code est écraséetle contexte est presque entièrement identique.

0xffSUICIDE dix Arrêtez l'exécution et enregistrez le compte pour une suppression ultérieure.
UN
s≡UN
′ s∪{jeun}
σ′[µs[0] mod 2160]b≡σ[µs[0] mod 2160]b+σ[jeun]b
σ′[jeun]b≡0 {
Rsuicide sijeun∈ / UNs
UNr≡UN
′ r+
0 sinon
{
gnouveau compte siσ[µs[1] mode 2160] =∅ 0
CSUICIDE(σ,µ)≡gsuicide+
sinon

annexeJE.Bloc Genèse
Le bloc de genèse est de 15 items, et est spécifié ainsi :
(( ( ( )) ( )) )
(226) 0256,KEC RLP (),0160, étatRoot,0,0,02048,217,0,0,3141592, temps,0,0256,KCE (42) , (),()
Où 0256fait référence au hachage parent, un hachage de 256 bits composé uniquement de zéros ; 0160fait référence à l'adresse du bénéficiaire, un hachage de 160 bits
composé uniquement de zéros ; 02048fait référence à la floraison du journal, 2048 bits de tous les zéros ; 217fait référence à la difficulté; la racine de trie de transaction, la
racine de trie de réception, le gaz utilisé, le numéro de bloc et les données supplémentaires sont tous deux 0, étant équivalant au tableau d'octets vide.
Les séquences des ommers et des transactions sont vides et représentées par ().KCE (42) fait référence au hachage Keccak
( ( ))
d'un tableau d'octets de longueur un dont le premier et unique octet vaut 42, utilisé pour le nonce.KEC RLP () la valeur fait référence à

le hachage des listes ommer dans RLP, les deux listes vides.
La série de preuves de concept comprend une prémine de développement, ce qui confère au hachage de la racine d'état une certaine valeur
stateRoot. Aussi tempssera défini sur l'horodatage initial du bloc de genèse. La documentation la plus récente doit être consultée pour ces valeurs.

annexeJÉthash
J.1.Définitions.Nous employons les définitions suivantes :
Nom Valeur Description

Jmotoctets 4 Octets dans le mot.

230
Jdatasetinit Octets dans l'ensemble de données à la
223 genèse. Croissance de l'ensemble de
Jcroissance du jeu de données
224
Jcache init données par époque. Octets en cache à la
217
Jcroissance du cache genèse. Croissance du cache par époque.

Jépoque 30000 Blocs par époque.

Jmélange d'octets 128 mélanger la longueur en octets.

Joctets de hachage 64 Longueur de hachage en octets.

Jparents 256 Nombre de parents de chaque élément de l'ensemble de

Jrondes de cache 3 données. Nombre de tours dans la production de cache.
Jaccède 64 Nombre d'accès dans la boucle hashimoto.

J.2.Taille du jeu de données et du cache.La taille du cache d'Ethashc∈Bet jeu de donnéesd∈Bdépendent de l'époque, qui à son
tour dépend du numéro de bloc.
⌊ ⌋
Hje
(227) Eépoque(Hje) =
Jépoque
La taille de la croissance de l'ensemble de données parJcroissance du jeu de donnéesoctets, et la taille du cache parJcroissance du cacheoctets, chaque époque. Afin
d'éviter une régularité conduisant à un comportement cyclique, la taille doit être un nombre premier. La taille est donc réduite de
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 31

un multiple deJmélange d'octets, pour le jeu de données, etJoctets de hachagepour le cache. Laisserdtaille=‖d‖être la taille de l'ensemble de données. Qui est
calculé à l'aide

(228) dtaille=Eprime(Jdatasetinit+Jcroissance du jeu de données·Eépoque− Jmélange d'octets, Jmélange d'octets)

La taille du cache,ctaille, est calculé en utilisant
(229) ctaille=Eprime(Jcache init+Jcroissance du cache·Eépoque− Joctets de hachage, Joctets de hachage)
{
X six/y∈P
(230) Eprime(x, y) =
Eprime(x−1·y, y) sinon

J.3.Génération de jeux de données.Pour générer le jeu de données, nous avons besoin du cachec,qui est un tableau d'octets. Cela dépend de la
taille du cachectailleet le hachage de grainess∈B32.

J.3.1.Hachage de graines.Le hachage de graines est différent pour chaque époque. Pour la première époque, il s'agit du hachage Keccak-256 d'une série de 32
octets de zéros. Pour toutes les autres époques, il s'agit toujours du hachage Keccak-256 du hachage de graine précédent :

(231) s =Chachage de graines(Hje)

{
KEC(032) siEépoque(Hje) = 0
(232) Chachage de graines(Hje) =
KEC(Chachage de graines(Hje− Jépoque)) sinon
Avec032étant 32 octets de zéros.

J.3.2.Cachette.Le processus de production de cache consiste à utiliser le hachage de départ pour d'abord remplir séquentiellementctaille
L'initiale
octets de mémoire, puis en effectuantJrondes de cachepasses de l'algorithme RandMemoHash créé par Lerner [2014]. cachec′, étant un
tableau de tableaux d'octets simples, sera construit comme suit.
On définit le tableaucje, composé de 64 octets simples, comme lejeème élément du cache initial :
{
KEC512(s) sije=0
(233) cje=
KEC512(cje-1) sinon
Doncc′peut être défini comme
(234) c′[je] =cje ∀ je <n
⌊ ⌋
ctaille
(235) n=
Joctets de hachage

Le cache est calculé en effectuantJrondes de cachetours de l'algorithme RandMemoHash dans le cache initialc′: (236)
c =Erondes de cache(c′, Jrondes de cache)
-
-X si y=0
(237) Erondes de cache(X, y) = ERMH(X) si y=1
--
Erondes de cache(ERMH(X), y −1) sinon
Où un seul tour modifie chaque sous-ensemble du cache comme suit :
( )
(238) ERMH(x) =Ermh(X,0),Ermh(X,1), ...,Ermh(X, n−1)

(239)Ermh(X, je) =KEC512(X′[(je -1 +n) modulen]⊕X′[X′[je][0] modulen])

avecX′=XsaufX′[j] =Ermh(X, j)∀j < je

J.3.3.Calcul du jeu de données complet.Essentiellement, nous combinons les données deJparentsnœuds de cache sélectionnés de manière pseudo-aléatoire et hachage pour
calculer l'ensemble de données. L'ensemble de données complet est ensuite généré par un certain nombre d'éléments, chacunJoctets de hachageoctets dans
taille:
⌊ ⌋
dtaille
(240) d[je] =Eélément de jeu de données(c, je)∀je <
Joctets de hachage

Pour calculer l'élément unique, nous utilisons un algorithme inspiré du hachage FNV (Glenn Fowler [1991]) dans certains cas
comme substitut non associatif de XOR.
(241) EFNV(X,y) = (x·(0x01000193⊕y)) mod 232
L'élément unique de l'ensemble de données peut maintenant être calculé comme : (242)

Eélément de jeu de données(c, je) =Eparents(c, je,−1,∅)

{
Eparents(c, je, p+1,Emélanger(m,c, je, p+1)) E sip < Jparents−2
(243) Eparents(c, je, p,m) =
mélanger(m,c, je, p+1) sinon
 ETHEREUM : UN LIVRE DE TRANSACTIONS GÉNÉRALISÉ DÉCENTRALISÉ ET SÉCURISÉ RÉVISION EIP-150 32

{
KEC512(c[je modectaille e]⊕je) sip=0
(244) Emélanger(m,c, je, p) = ( )
EFNVm,c[EFNV(je⊕p,m[p modebJoctets de hachage/Jmotoctetsc]) modectaille] sinon
J.4.Fonction de preuve de travail.Essentiellement, nous maintenons un "mélange"Jmélange d'octetsoctets de large, et récupérer séquentiellement à plusieurs
reprises Jmélange d'octetsoctets de l'ensemble de données complet et utilisez leEFNVfonction pour le combiner avec le mélange.Jmélange d'octetsdes octets d'accès
séquentiel sont utilisés de sorte que chaque tour de l'algorithme récupère toujours une page complète de la RAM, minimisant les échecs de mémoire tampon
de recherche de traduction que les ASIC pourraient théoriquement éviter.
Si la sortie de cet algorithme est inférieure à la cible souhaitée, alors le nonce est valide. Notez que l'application supplémentaire de
KECà la fin s'assure qu'il existe un nonce intermédiaire qui peut être fourni pour prouver qu'au moins une petite quantité de travail a été
effectuée ; cette vérification PoW externe rapide peut être utilisée à des fins anti-DDoS. Il sert également à fournir l'assurance statistique
que le résultat est un nombre non biaisé de 256 bits.
La fonction PoW renvoie un tableau avec le mélange compressé comme premier élément et le hachage Keccak-256 de la
concaténation du mélange compressé avec le hachage de départ comme deuxième élément :
(245)
PoW(Hn,Hn,ré) ={mc(KEC(RLP(LH(Hn))),Hn,d),KEC(sh(KEC(RLP(LH(Hn))),Hn) +mc(KEC(RLP(LH(Hn))),Hn,d))}
AvecHn étant le hachage de l'en-tête sans le nonce. Le mélange compressémcest obtenu comme suit :
n∑
mélanger

(246) mc(h,n,ré) =Ecompresse(Eaccède(d, sh(h,n),sh(h,n),−1),−4)

je=0
Le hachage de graines étant :

(247) sh(h,n) =KEC512(h +Erevenir(n))

Erevenir(n)renvoie la séquence d'octets inversés du noncen :
(248) Erevenir(n)[je] =n[‖n‖−je]
Nous notons que l'opérateur "+" entre deux séquences d'octets entraîne la concaténation des deux séquences.
Le jeu de donnéesdest obtenu comme décrit dans la section J.3.3.
Le nombre de séquences répliquées dans le mix est :
⌊ ⌋
Jmélange d'octets
(249) nmélanger=
Joctets de hachage
Afin d'ajouter des nœuds de jeu de données aléatoires au mélange, leEaccèdefonction est utilisée :
{
Emixdataset(d,m,s, je) sije=Jaccède−2
(250) Eaccède(d,m,s, je) =
Eaccède(Emixdataset(d,m,s, je),s, je+1) sinon

(251) Emixdataset(d,m,s, je) =EFNV(m,Enouvelles données(d,m,s, je)

Enouvelles donnéesretourne un tableau avecnmélangeréléments :
(252)
⌊ ⌋ ⌊ ⌋
Jmélanger es ]) dtaille /Jhashby
Enouvelles données(d,m,s, je)[j] =d[EFNV(je⊕s[0],m[je mode mode tes ·nmélanger+j] ∀j < nmélanger
Jmotoctets nmélanger

Le mix est compressé comme suit :

(253) {
m sije>‖m‖−8
Ecompresse(m, je) =
Ecompresse(EFNV(EFNV(EFNV(m[je+4],m[je+5]),m[je+6]),m[je+7]), je+8) sinon