Introduction et avant propos

Qu’il a été dur de comprendre comment fonctionne Ethereum mais ça y est ! Dans les grandes lignes du moins. Je commence ce résumé pour la troisième fois après plus de vingt heures passée à lire de la doc, des documents de toutes sortes, me faire aider par des IAs et faire des croquis, tout ça pour comprendre au mieux les sujets qui suivent.

Dans ce résumé, il est très important de faire attention à la façon dont son nommées les choses. Je vous invite vraiment à le lire plusieurs fois si vous voulez bien comprendre ce qui y est dit. Bonne lecture !

But d’Ethereum

Le but d’Ethereum est de créer un protocole grâce auquel il est possible de construire des applications décentralisées.

Ethereum fait cela en construisant ce qui est essentiellement la couche fondamentale abstraite ultime : une blockchain intégrant un langage de programmation, permettant à quiconque de rédiger des smarts contracts (contrats autonomes) et des applications décentralisées où l’on peut créer ses propres règles.

Historique

Les principes clés d’Ethereum sont, dans l’ordre chronologique d’apparition :

• EVM et smarts contracts – 2015
• Layers 2 – 2018 à 2019 (on verra ça une prochaine fois)
• Proof of Stake – 2022

Pour écrire ce dossier, je me suis beaucoup basé sur le white paper d’Ethereum, c’est le papier fondateur qui présente le projet avant même qu’il existe. https://ethereum.org/fr/whitepaper/
Même si ce dernier date et n’est plus à jour sur tous les sujets, il englobe les idées fondamentales du protocole, la vision d’ensemble du projet et les idées à la genèse de ce dernier.

Si vous avez eu la bonne idée d’aller jeter un coup d’œil au papier fondateur de Bitcoin dans le résumé précédent, allez comprendre que notre cerveau n’est pas assez gros en lisant les 3 premières pages du papier fondateur du code d’Ethereum : https://ethereum.github.io/yellowpaper/paper.pdf

Smart contrat

Sans rentrer dans les détails, un contrat intelligent est un contrat qui est codé. Il permet de pouvoir se passer d’une third party qui vérifierait qu’un contrat entre deux personnes est bien honoré par les deux. Il fait cela en codant les différents aspects du contrat, exactement comme dans n’importe quel logiciel informatique.

Un petit exemple pour se donner une idée serait : Dwayne veux prendre un taxi de A à B dont le trajet va coûter 15 CHF. Le contrat stipule que pour avoir accès à la réservation du taxi, Dwayne doit bloquer 15 CHF dans le contrat. Il bloque donc 15 CHF dans le contrat ce qui lui permet de commander un taxi. Une fois ceci fait, le taxi pourra récupérer la somme bloquée dans le contrat quand le GPS du téléphone de Dwayne aura indiqué au contrat qu’il est bien dans la zone d’arrivée de la course.

C’est un exemple simple qui permet de comprendre que les conditions du contrat sont codées en dur. On ne peut pas tricher ou se battre à coup d’avocat. Si deux parties décident d’utiliser un même contrat c’est qu’elles acceptent les termes de celui-ci et n’ont plus d’autre choix que de l’honorer.

Deux choses pour la suite :

• Retenez cet exemple que je réutiliserais
• J’utiliserais simplement le terme de contrat car c’est ce qui est utilisé dans le white paper en français mais en général on parle de smart contrat.

Les limites du possible d’un contrat Ethereum sont énormes et il y en a sans cesse de nouvelles. Cependant, avec le simple exemple utilisé ci-dessus, il est possible de comprendre le principal, un smart contract est un contrat entièrement codé.

Nous allons voir ci-dessous que sur Ethereum, il existe deux type de compte. Le premier pour les utilisateurs standard et un deuxième spécifiquement pour contenir des smarts contracts.

Les deux types de comptes

Tout compte Ethereum contient plusieurs champs :

• Un nonce, un compteur pour être sûr qu’une transaction ne peut être faite qu’une fois car il s’incrémente de 1 à chaque transaction
• La balance actuelle du compte
• Le code du contrat, si présent
• Le stockage du compte (vide par défaut)

Sur Ethereum il existe deux types de comptes et nous allons comprendre pourquoi cette mécanique est importante. Ces deux types sont les suivants :

• Compte de détenteur externe, contrôlé par une clé privée (comme un compte Bitcoin). Il n’a pas de code et on peut envoyer des messages à partir de celui-ci en créant et en signant une transaction. Dans le white paper, un tel compte est appelé EOA pour External Operated Account. C’est le type de compte associé à un utilisateur standard, un humain quoi.
• Compte de contrat, commandé par le code du contrat. Chaque fois qu’un compte de ce type reçois un message, son code s’active, ce qui lui permet de lire et écrire dans la mémoire de stockage interne et d’envoyer d’autres messages ou de créer des contrats à son tour. Un tel compte permet en fin de compte de faire détenir et d’activer le code du smart contract

Lien avec les smarts contracts

Il est primordial de comprendre que les contrats dans Ethereum exécutent toujours un bout de code spécifique lorsqu’ils sont appelés par un message ou une transaction. Ils conservent aussi le contrôle direct de leur solde en ETH et de leur collection de clés et valeurs stockées en internes. En d’autres termes, un contrat a les mêmes droit qu’un acteur externe a sur son compte.

Si je résume, un EOA est donc un compte qui est contrôlé par “un humain” tandis qu’un compte de contrat est contrôlé par le code du smart contrat qui lui est associé. Ainsi si je veux utiliser un contrat, je n’ai qu’à envoyer un message à son compte.

Transaction et message

On l’a compris, Ethereum fait donc un différence entre une transaction et un message. Il est important de comprendre la différence afin de rester précis dans la terminologie.

En parlant de terminologie, ce qui s’apparente à un mineur sur Bitcoin est appelé validateur sur Ethereum.

Transaction

Notons au passage que lorsqu’un validateur (mineur pour Ethereum) veut proposer un nouveau bloc, il propose un collection de transactions. Dans l’idée, ce processus est très similaire à Bitcoin.

Une transactions contient :

• Destinataire
• Signature identifiant l’expéditeur
• La quantité d’ETH à transférer de l’expéditeur au destinataire
• Un champ optionnel de données. Permettrait, dans l’exemple du taxi, d’informer le smart contrat du point de départ et d’arrivée de la course.
• Une valeur gasLimit. Elle représente le nombre maximum de calcul autorisé pour l’exécution de la transaction.
• Une valeur maxFeePerGas . Elle représente les frais que l’expéditeur paie par étape de calcul.

On va revenir très vite sur la notion de gas. Pour l’instant il faut retenir que c’est une des variables a inclure dans une transaction.

Message

Si on prend le temps de comprendre cela c’est parce que c’est important pour la suite. Mais ne vous inquiétez pas, vous serez bien assez vite perdu et une deuxième lecture sera de rigueur (il m’en a fallu 50 ^^).

Jusque là on a donc vu qu’il existe deux types de comptes, un pour les smart contracts et un EOA. En fonction du type de compte de l’expéditeur on appel ça une transaction pour un EOA -> autre, ou un message pour smart contract -> autre. Finalement on peut très grossièrement résumer un smart contract comme un bout de code.

L’EVM

On y arrive, le cœur du sujet lorsqu’il s’agit d’Ethereum.

Contrairement à Bitcoin, qui est surtout conçu pour être une monnaie numérique, Ethereum permet aux développeurs de créer des applications décentralisées (DApps) et d’automatiser des accords via des smart contrat. Ethereum a apporté une dimension de programmabilité qui n’était pas aussi facilement disponible avant. On entend souvent le terme “EVM” lorsqu’on s’intéresse aux cryptomonnaies. C’est un composant central à Ethereum car c’est ce qui permet toute sa puissance.

L’EVM c’est l’Ethereum Virtual Machine, une machine virtuelle qui tourne sur chaque nœud du réseau d’Ethereum. Elle est évidemment la même sur tout les nœuds du réseau pour que ses résultats soient les mêmes, peu importe sur quel nœud l’exécution à lieu. J’entends par là que son code et ses règles sont les mêmes partout, ainsi même règles = même résultat.

J’ai eu beaucoup de peine à comprendre ce qui se cache derrière la notion d’EVM. Il me semble que comprendre le contexte dans lequel elle a lieu et où elle opère est la meilleure façon d’en cerner l’utilité. Pour mieux comprendre appuyons nous sur le schéma suivant :

On va disséquer chaque étape mais n’hésitez pas à ouvrir le schéma dans un nouvel onglet pour l’avoir sous la main et y revenir facilement si besoin.

1. Création du bloc

C’est la première étape du schéma. Comme le fait un mineur sur Bitcoin, un validateur sur Ethereum propose un bloc contenant une collection de transactions.

Première chose à comprendre :

Dans l’exemple du taxi, Dwayne fait une transaction au contrat avec une certaine somme et des instructions. Les instructions sont libres, dans notre exemple Dwayne aurait peut être à dire au contrat qu’il veut réserver un taxi entre A et B.

Dans la création du bloc par le validateur il n’y a qu’une collection de transactions. On peut le voir comme une collection d’instructions qui ont été émises par des EAO.

Mais ces contrats sont des bouts de code dont le résultat doivent être calculés.

2. Exécution par l’EVM

Pour le dire grossièrement : Une fois que le validateur à créé son bloc, le code qui doit être exécuté est distribué a d’autre nœuds qui forment l’EVM et exécutent le code. On l’a vu, peu importe quel nœud exécute quelle transaction, le résultat sera le même dans tout les cas.

L’EVM exécute donc le code d’un smart contract qui est contacté par une transaction.

Dans le schéma ci-dessus, on peut voir qu’un contrat peut en appeler un autre si son code en a besoin et cela autant de fois que nécessaire. On peut même faire des chaînes de contrat. Cela permet de développer des applications puissantes où on a la possibilité de ne mettre à jour qu’une partie du code si besoin.

On comprend mieux ce qu’est l’EVM : c’est l’environnement virtuel, distribué chez tout les validateurs, qui permet d’exécuter le code des contrats afin d’obtenir les résultats de toute les transactions contenue dans un bloc.

On voit aussi bien la distinction entre transactions et messages.

Reprenons donc depuis le début. Un validateur propose un nouveau bloc puis l’EVM exécute les smarts contrats. Une fois l’exécution faite, les conséquences des transactions comprises dans le bloc d’origine sont connues et appliquées pour mettre à jour l’état de tout les comptes qui ont été impactés.

Pour prendre un peu de recul, quand un mineur propose un bloc dans Bitcoin, le processus s’arrête là. Dans Ethereum après la proposition de bloc par un validateur, vient une étape d’exécution des smarts contrat dans l’EVM.

3. Validation par les autres nœuds

Avant d’ajouter le bloc final (comme je l’ai appelé dans le schéma dessus) à la blockchain, les validateurs vérifient que les transactions sont bonnes et que l’exécution de l’EVM est correcte. Si c’est le cas, le bloc final est ajouté à la blockchain.

De nouveau et pour bien comprendre, en comparaison avec Bitcoin qui ajoute le bloc proposé à la blockchain après que ses transactions soient vérifiées, dans Ethereum ce n’est pas le bloc initialement proposé qui est ajouté à la blockchain. C’est le bloc une fois que l’EVM a exécuté l’ensemble des smart contrats nécessaire au bloc initial qui est ajouté à la blockchain.

Résumé

Il est important de noter que chaque validateur qui participe au réseau a plusieurs tâches :

• Création de nouveaux blocs
• Participation à l’EVM
• Validation des blocs de la blockchain

En fait, un validateur participe à l’ensemble des processus que nous avons vu ci-dessus.

J’ai eu beaucoup de mal à comprendre ce que c’est que l’EVM car j’en ai toujours entendu parlé comme d’une sorte d’entité magique à part entière. Il n’en est rien, on peut même maintenant se vanter de comprendre que :

“L’EVM est une machine virtuelle déterministe exécutée par chaque nœud Ethereum.
Elle interprète le bytecode des smart contracts, exécute les instructions, et met à jour l’état global du réseau de manière identique sur tous les nœuds.
Elle fonctionne comme un environnement d’exécution isolé.
L’EVM garantit que tous les nœuds reproduisent exactement le même résultat à partir des mêmes transactions, assurant la cohérence de l’état de la blockchain.”

Nous avons vu jusqu’ici :

• Des transactions EOA → Contrat ✅
• Des messages Contrat → Contrat ✅

Et pour une transaction EOA → EOA qui serait un simple transfère de fond ? Excellente question !

Une transactions entre deux EOA suit le même processus que celui qu’on a vu jusqu’ici. Elle est aussi exécutée dans l’EVM et a un coût fixe puisque c’est toujours la même opération. Ce coût est de 21’000 gas, 21’000 QUOI ?!

Gas

L’exécution de l’EVM demande des ressources matériels et énergétiques. Une simple transaction ou une chaîne de contrat complexe ne coûtent pas la même chose en ressources. N’oublions pas non plus que l’exécution peut être faite par n’importe quel validateur choisi au hasard et que celui-ci doit être rémunérer en fonction.

Pour cela une unité a été créée dans le protocole d’Ethereum, c’est le gas (qui est prononcé “gaz”). Chaque opération a un coût défini en gas. On connaît le nombre d’opérations que va faire un contrat et on connaît la nature de chaque opération. On peut donc définir le coût en gas de chaque contrat

1 étape de calcul simple	1 gas
opération de calcul avancée	plusieurs gas en fonction de l’opération
1 octet de donnée de transaction	5 gas
1 transaction	21’000 gas
…

Dans le schéma ci-dessous (les valeurs sont absurdes), on sait qu’un contrat A a besoin de 30 opérations pour être exécuté. On peut donc connaître son coût en gas, 500 dans l’exemple.

Le prix a payer par gas varie en fonction de la congestion du réseau, il est dicté par l’offre et la demande. Allez checker le prix en direct ici : https://etherscan.io/gastracker (Note : 1’000’000’000 Gwei = 1 Ether)

Dans mon exemple on multiplie le coût en gas par son prix et on obtient le prix final que devra payer l’utilisateur en ETH pour voir son opération exécutée, ici 0,5 ETH.

Comme je le mentionne plus haut une transaction contient plusieurs choses dont les valeurs maxFeePerGas et gasLimit.

maxFeePerGas

Cette valeur représente le montant maximum que l’utilisateur accepte de payer par unité de gas. Sachant que le prix réel du gas est dicté par l’offre et la demande en temps réel, il change à chaque seconde. Ce montant permet donc de ne pas avoir de mauvaise surprise si le prix du gas explose entre le moment où on vérifie son prix et le moment où notre transaction est exécutée.

Le protocole garantit donc qu’on ne paye pas plus qu’un montant défini par gas. En plus de ça, si on veut que notre transaction passe le plus vite possible, il est possible de donner une valeur maxPriorityFeePerGas (tip). Elle permet de donner un pourboire au validateur et l’inciter à inclure notre transaction dans le prochain bloc.

gasLimit

C’est le maximum de gas qu’une transaction peut consommer.

Supposons que A est un acteur externe, B et C des contrats. Si A veut interagir avec le contrat B qui lui même va interagir avec le contrat C, ****le schéma est le suivant :

A → B : est une transaction car A est un acteur externe. A a défini gasLimit de 1000 gas qui sont envoyés

B consomme 600 gas : il reste 400 gas. Si B a besoin d’avoir recours à un contrat C, il pourra consommer au maximum ces 400 gas.

B → C : est un message car un B et C sont des contrats

Si C consomme 300 gas, il reste 100 gas qui peuvent être utilisés par B ou renvoyés à A.

Exemple d’acteur malveillant

Si il n’y avait pas de gasLimit, un acteur malveillant pourrait bloquer les autres validateurs dans des contrat infini. Grâce à la gasLimit, un validateur connaît à l’avance les intentions en nombre de calcul qu’une transaction comporte.

baseFee

Pendant que nous sommes dans les frais, je mentionne encore la taxe de base. C’est une taxe obligatoire pour toute les transactions qui est définie à chaque bloc par le protocole Ethereum. Elle varie en fonction de la congestion du réseau, plus la congestion est grande, plus la taxe de base l’est. Cela permet d’inciter les transactions non essentielles à être faite plus tard.

Les éthers récoltés par cette taxe de base sont brûlés. C’est un mécanisme économique qui fait augmenter la rareté des éthers au court du temps.

Résumé

On a compris comment les nœuds sont rémunérés pour leur participation à l’exécution de l’EVM.

On comprend aussi maintenant ce que veut dire qu’une transaction entre deux EOA a un coût de 21000 gas.

Le but de ce système de frais est d’exiger d’un attaquant qu’il paie proportionnellement chaque ressource qu’il consomme, ceci comprenant le calcul, la bande passante et le stockage ; par conséquent, toute transaction qui conduit le réseau à consommer une plus grande quantité de l’une de ces ressources doit payer des frais en gas à peu près proportionnels à cette augmentation.

Proof of Stake

Dernier gros sujet que j’aimerais aborder sur Ethereum : le Proof of Stake. On a largement vu comment fonctionne le PoW de Bitcoin. A la base Ethereum fonctionnait sur le même mécanisme mais celui-ci était considéré comme trop énergivore. Lors de la mise à jour majeure du protocole du 15 septembre 2022, appelée “The Merge”, Ethereum est passé à un consensus PoS.

A la place de prouver sa bonne fois par le travail, un validateur en PoS va immobiliser un capital important. Pour devenir validateur Ethereum il faut déposer 32 ETH, on parle de staker des ETH.

Pour définir qui sera sélectionné pour proposer son bloc, le protocole choisi aléatoirement un validateur mais en proportion des ETH qu’il a staké. Plus un validateur à staké d’ETH, plus il a de chance de proposer un bloc et de recevoir la récompense associée. Par contre, la pénalité pour un validateur malveillant est proportionnelle au stake et amplifiée si d’autres validateurs commettent la même faute simultanément.

On pourrait dire beaucoup de chose sur le PoS et le comparer pendant des heures au PoW. Je vous laisse cependant avec ces quelques points :

Critère	Proof of Stake (PoS)	Proof of Work (PoW)
Sécurité	Sécurité dépendante du capital requis (stake). Attaque coûteuse mais théoriquement achetable.	Sécurité dépendante de la puissance de calcul. Attaque 51% extrêmement coûteuse en matériel + énergie.
Coût énergétique	Très faible.	Très élevé.
Décentralisation réelle	Risque de concentration des gros stakers et des plateformes de staking.	Risque de concentration des pools de minage, mais barrière matérielle plus diversifiée.
Barrière d’entrée	Faible (staking via services), très faible techniquement.	Très élevée (matériel spécialisé, électricité).
Évolutivité protocolaire	Plus simple à mettre à jour, mécaniquement.	Changements plus lourds car affectent matériel/minage.
Impact environnemental	Très faible.	Très élevé.
Alignement incitatif	Le validateur met son propre capital en jeu.	Le mineur investit en matériel ; risque plus “opérationnel” que capital immobilisé.

Si vous avez bien compris ce résumé, nulle doute que vous saurez comprendre les points ci-dessus.

Conclusion

Dans ce résumé, le plus technique jusque là, on a vu plusieurs notions importantes pour la compréhension d’Ethereum. Il faut s’accrocher mais on commence à toucher du doigt les processus balèzes. Souvenez vous aussi que les notions de smart contrat et d’EVM sont là depuis 2014, ça paraît révolutionnaire et ça a plus de 10 ans alors vivement la suite !

On a vu que derrière le mot “crypto” qui est prononcé avec dédain au téléjournal se cache des processus complexes, on est pas seulement sur des scams et des outils spéculatifs pour personne en manque d’adrénaline. Cette technologie est un peu plus poussée qu’un jeu mobile de collection de cookie.

Notes personnelles

D’un point de vue personnel ce résumé m’a bien cassé la tête. Je n’avais jusque là jamais osé me plonger à fond dans la compréhension d’Ethereum mais c’est chose faite. Il faut dire que la collection de neurone des gars qui participent à l’élaboration de tels protocoles est largement supérieur à la mienne. On pourrait y trouver un lien avec le musée du Louvre versus le musée de la grenouille d’Estavayer. Tout ça pour dire que je n’ai pas trouvé de document qui explique les choses comme je l’ai fait dans ce résumé.

Si ce genre de résumés continuent de vous intéresser j’en suis ravis ! Pour les prochains, j’essaierais d’aborder des sujets plus petits. Il me semblait cependant important d’attaquer les choses dans l’ordre et on ne pouvait pas passer à côté d’Ethereum.