Le livre blanc d’Ethereum et l’EVM

Curiosité

1. Pourquoi un ordinateur répliqué sur des milliers de machines doit-il faire payer chacune de ses instructions ?
2. Qu’est-ce qui ne fonctionne plus si le code exécuté sur ces machines peut boucler indéfiniment sans pénalité ?
3. Comment deux modèles de comptes différents — les UTXO et les soldes mis à jour sur place — peuvent-ils représenter différemment la même richesse ?

Explorer

1. Vitalik Buterin, alors âgé de dix-neuf ans, a rédigé le livre blanc d’Ethereum à la fin de 2013, proposant une plateforme de calcul généraliste plutôt qu’une monnaie spécifique. Le projet, annoncé publiquement en janvier 2014, a réuni des cofondateurs dont Gavin Wood, Joseph Lubin, Charles Hoskinson, Anthony Di Iorio et Mihai Alisie. Une vente publique de tokens (crowdsale) s’est déroulée de juillet à août 2014 et a permis de lever environ 31 500 BTC pour le projet. Le réseau a été officiellement lancé le 30 juillet 2015, marquant le passage du langage de script limité de bitcoin à un environnement entièrement programmable, où les développeurs pouvaient créer des applications complexes directement on-chain.
2. Le cœur de cette architecture est la machine virtuelle d’Ethereum (EVM), une machine à états Turing-complète répliquée sur chaque nœud complet. Contrairement au modèle UTXO de bitcoin, qui suit individuellement chaque sortie non dépensée, Ethereum utilise un modèle de comptes dans lequel les soldes sont mis à jour sur place. Chaque compte — qu’il soit contrôlé par une clé privée ou par du code — conserve un nonce et un solde. Lorsqu’une transaction est exécutée, l’EVM la traite de manière déterministe ; chaque nœud calcule le même résultat de son côté, ce qui assure le consensus sans exiger de confiance entre les participants.
3. Les smart contracts sont des programmes écrits dans des langages de haut niveau comme Solidity, compilés en opcodes de bas niveau exécutés par l’EVM. Ces contrats contiennent à la fois de la valeur et de la logique. Un contrat peut détenir de l’ether, exécuter des échanges conditionnels ou gérer des votes de gouvernance en fonction des données transmises par d’autres comptes. Comme l’exécution est déterministe et que de nombreux contrats publient leur code source, chacun peut en vérifier la logique avant d’interagir avec eux. Cette transparence supprime le besoin d’intermédiaires de confiance dans de nombreuses applications financières, puisque les règles sont appliquées par le logiciel plutôt que par une appréciation humaine.
4. Pour empêcher les boucles infinies et les attaques par déni de service, chaque opération de l’EVM consomme du « gaz », une unité de calcul payée en ether. L’expéditeur fixe à l’avance une limite de gaz ; si l’exécution épuise ce carburant, les changements d’état sont annulés, mais le gaz consommé reste prélevé. Cette contrainte économique oblige les développeurs à écrire du code efficace et protège le réseau contre les contrats malveillants ou bogués qui pourraient sinon paralyser la chaîne. Le prix du gaz monte et descend avec la demande : à l’origine, les utilisateurs faisaient simplement une offre ; depuis 2021, des frais de base (base fee) fixés par le protocole s’ajustent automatiquement, auxquels s’ajoute un pourboire (voir une leçon ultérieure).
5. Les choix de conception de l’EVM traduisent un compromis entre expressivité et sécurité. La complétude de Turing permet des calculs arbitraires, mais introduit une complexité susceptible de receler des vulnérabilités. Le modèle de comptes rend certains programmes plus simples qu’avec des UTXO, mais les contrats qui s’appellent les uns les autres doivent être écrits avec soin pour éviter des bugs comme la réentrance, la faille à l’origine du piratage de The DAO (voir une leçon ultérieure). La standardisation de l’EVM a permis l’essor d’un vaste écosystème d’outils et d’auditeurs familiers de ce jeu d’instructions.
6. Ouvrez un explorateur de blocs comme Etherscan et examinez une transaction récente ayant déployé un smart contract. Observez le statut « Contract Creation » ainsi que le gaz utilisé par rapport à la limite de gaz. Remarquez que les données d’entrée (input data) de la transaction contiennent le bytecode compilé qui est stocké à la nouvelle adresse. Cette étape concrète montre la réalité mécanique du déploiement : le code est envoyé, vérifié par chaque nœud et inscrit dans la machine à états de la chaîne, prêt à être exécuté lors d’interactions futures.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• V. Buterin, 'Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform' (2013/2014)
• G. Wood, 'Ethereum: A Secure Decentralised Generalised Transaction Ledger' (Yellow Paper, 2014)
• ethereum.org, 'History of Ethereum'