Ethereum : Plateforme de contrats intelligents et d'applications décentralisées de nouvelle génération
Abstract
Satoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or intrinsic value and no centralized issuer or controller. However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments (colored coins), the ownership of an underlying physical device (smart property), non-fungible assets such as domain names (Namecoin), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules (smart contracts) or even blockchain-based decentralized autonomous organizations (DAOs).
What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code. A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty lines. Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness, and state.
Abstract
Ethereum est une plateforme de cryptomonnaie et d'application decentralisee de nouvelle generation qui introduit une blockchain dotee d'un langage de programmation Turing-complet integre. Cela permet a quiconque d'ecrire des smart contracts et des applications decentralisees dans lesquels ils peuvent creer leurs propres regles arbitraires de propriete, de formats de transaction et de fonctions de transition d'etat.
L'innovation fondamentale d'Ethereum est de combiner la technologie blockchain pionnierement developpee par Bitcoin avec un environnement de programmation generaliste. Alors que Bitcoin fournit un simple systeme de transition d'etat pour deplacer de la monnaie d'un compte a un autre, Ethereum fournit une plateforme ou les developpeurs peuvent construire tout type d'application decentralisee qu'ils peuvent imaginer, des monnaies alternatives et instruments financiers aux systemes d'enregistrement de noms de domaine et aux organisations decentralisees.
Ethereum y parvient en construisant ce qui est essentiellement la couche fondationnelle abstraite ultime : une blockchain avec un langage de programmation Turing-complet integre, permettant a quiconque d'ecrire des smart contracts et des applications decentralisees dans lesquels ils peuvent creer leurs propres regles arbitraires de propriete, de formats de transaction et de fonctions de transition d'etat. Une version minimale de Namecoin peut etre ecrite en deux lignes de code, et d'autres protocoles comme les monnaies et les systemes de reputation peuvent etre construits en moins de vingt.
Introduction and Existing Concepts
The concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades. The anonymous e-cash protocols of the 1980s and the 1990s, mostly reliant on a cryptographic primitive known as Chaumian blinding, provided a currency with a high degree of privacy, but the protocols largely failed to gain traction because of their reliance on a centralized intermediary. In 1998, Wei Dai's b-money became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented. In 2005, Hal Finney introduced a concept of reusable proofs of work, a system which uses ideas from b-money together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend.
In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as "proof of work." The mechanism behind proof of work was a breakthrough in the space because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier -- the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings. Since then, an alternative approach has been proposed called proof of stake, calculating the weight of a node as being proportional to its currency holdings and not computational resources; the discussion of the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.
The Bitcoin blockchain has proven remarkably robust in practice over the subsequent years of operation, but it is inherently limited in what it can accomplish beyond simple value transfer. Bitcoin's scripting language is intentionally designed to be restrictive, lacking loops, Turing-completeness, and many other features that would be necessary to build more complex applications. This limitation, while providing safety from certain classes of attacks, severely restricts what can be built on top of Bitcoin. Over the following years, numerous attempts to extend Bitcoin's functionality emerged: colored coins sought to use the Bitcoin blockchain to track ownership of alternative assets, Namecoin attempted to create a decentralized name registration database, and various metacoin protocols aimed to build additional layers on top of Bitcoin's transaction format. While these approaches showed promise, they were ultimately constrained by Bitcoin's scripting capabilities and the inability to access blockchain data from within scripts.
What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.
Introduction and Existing Concepts
Le concept de monnaie numerique decentralisee, ainsi que les applications alternatives comme les registres de propriete, existe depuis des decennies. Les protocoles anonymes de monnaie electronique des annees 1980 et 1990, principalement fondes sur une primitive cryptographique connue sous le nom de blinding de Chaum, fournissaient une monnaie avec un haut degre de confidentialite, mais ces protocoles n'ont largement pas reussi a gagner du terrain en raison de leur dependance a un intermediaire centralise. En 1998, le b-money de Wei Dai est devenu la premiere proposition a introduire l'idee de creer de la monnaie en resolvant des puzzles computationnels ainsi qu'un consensus decentralise, mais la proposition etait peu detaillee quant a la facon dont le consensus decentralise pourrait effectivement etre mis en oeuvre.
En 2009, une monnaie decentralisee a ete pour la premiere fois implementee en pratique par Satoshi Nakamoto, combinant des primitives etablies pour la gestion de la propriete par la cryptographie a cle publique avec un algorithme de consensus pour suivre qui possede les coins, connu sous le nom de "preuve de travail". Le mecanisme derriere la preuve de travail a constitue une percee dans le domaine car il resolvait simultanement deux problemes. Premierement, il fournissait un algorithme de consensus simple et moderement efficace, permettant aux noeuds du reseau de s'accorder collectivement sur un ensemble de mises a jour canoniques de l'etat du registre Bitcoin. Deuxiemement, il fournissait un mecanisme permettant l'entree libre dans le processus de consensus, resolvant le probleme politique de decider qui peut influencer le consensus, tout en empechant simultanement les attaques Sybil.
La blockchain Bitcoin s'est averee remarquablement robuste au fil de ses annees de fonctionnement, mais elle est inheremment limitee. Le langage de script de Bitcoin est intentionnellement concu pour etre restrictif et non-Turing-complet, depourvu de boucles et de nombreuses autres fonctionnalites qui seraient necessaires pour construire des applications plus complexes. Cette limitation existe pour prevenir les boucles infinies et d'autres formes d'attaques computationnelles, mais elle restreint severement ce qui peut etre construit au-dessus de Bitcoin.
Au cours des cinq dernieres annees, il y a eu un certain nombre de tentatives pour etendre les fonctionnalites de Bitcoin. Les colored coins cherchaient a utiliser la blockchain Bitcoin pour suivre la propriete d'actifs alternatifs, Namecoin a tente de creer une base de donnees decentralisee d'enregistrement de noms, et divers protocoles de metacoin visaient a construire des couches supplementaires au-dessus de Bitcoin. Bien que ces approches aient montre des promesses, elles etaient finalement limitees par les capacites de script de Bitcoin et l'impossibilite d'acceder aux donnees de la blockchain depuis les scripts.
Ce qu'Ethereum entend fournir est une blockchain avec un langage de programmation Turing-complet pleinement developpe integre, qui peut etre utilise pour creer des "contrats" pouvant encoder des fonctions de transition d'etat arbitraires, permettant aux utilisateurs de creer n'importe lequel des systemes decrits ci-dessus, ainsi que de nombreux autres que nous n'avons pas encore imagines, simplement en ecrivant la logique en quelques lignes de code.
Bitcoin As A State Transition System
From a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a "state" consisting of the ownership status of all existing bitcoins and a "state transition function" that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move \(X from A to B, and the state transition function reduces the value in A's account by \)X and increases the value in B's account by \(X. If A's account has less than \)X in the first place, the state transition function returns an error. Hence, one can formally define:
APPLY(S,TX) - S' or ERROR
In the banking system defined above:
APPLY({ Alice: \(50, Bob: \)50 },send \(20 from Alice to Bob") = { Alice: \)30, Bob: $70 }
But:
APPLY({ Alice: \(50, Bob: \)50 },send $70 from Alice to Bob) = ERROR
The "state" in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO to be added to the state.
The state transition function APPLY(S,TX) - S' can be defined roughly as follows:
- For each input in TX:
- If the referenced UTXO is not in S, return an error.
- If the provided signature does not match the owner of the UTXO, return an error.
- If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error.
- Return S with all input UTXO removed and all output UTXO added.
The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value. In order to use this for payment, the protocol is as follows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC. Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12. She then creates a transaction with those three inputs and two outputs. The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC "change", with the owner being Alice herself.
Bitcoin As A State Transition System
D'un point de vue technique, le registre d'une cryptomonnaie telle que Bitcoin peut etre considere comme un systeme de transition d'etat, ou il y a un "etat" constitue du statut de propriete de tous les bitcoins existants et une "fonction de transition d'etat" qui prend un etat et une transaction et produit un nouvel etat qui en est le resultat. Dans un systeme bancaire standard, par exemple, l'etat est un bilan, une transaction est une demande de transfert de \(X de A vers B, et la fonction de transition d'etat reduit la valeur du compte de A de \)X et augmente la valeur du compte de B de \(X. Si le compte de A a moins de \)X au depart, la fonction de transition d'etat renvoie une erreur.
L'"etat" dans Bitcoin est la collection de tous les coins (techniquement, les "sorties de transaction non depensees" ou UTXO) qui ont ete emis et pas encore depenses, chaque UTXO ayant une denomination et un proprietaire (defini par une adresse de 20 octets qui est essentiellement une cle publique cryptographique). Une transaction contient une ou plusieurs entrees, chaque entree contenant une reference a un UTXO existant et une signature cryptographique produite par la cle privee associee a l'adresse du proprietaire, et une ou plusieurs sorties, chaque sortie contenant un nouvel UTXO a ajouter a l'etat.
La fonction de transition d'etat APPLY(S,TX) - S' peut etre definie approximativement comme suit :
- Pour chaque entree dans TX, si l'UTXO reference n'est pas dans S, renvoyer une erreur.
- Si la signature fournie ne correspond pas au proprietaire de l'UTXO, renvoyer une erreur.
- Si la somme des denominations de tous les UTXO d'entree est inferieure a la somme des denominations de tous les UTXO de sortie, renvoyer une erreur.
- Renvoyer S avec tous les UTXO d'entree supprimes et tous les UTXO de sortie ajoutes.
La premiere moitie de la premiere etape empeche les expediteurs de transactions de depenser des coins qui n'existent pas, la seconde moitie de la premiere etape empeche les expediteurs de transactions de depenser les coins d'autres personnes, et la deuxieme etape impose la conservation de la valeur. Pour utiliser ceci pour un paiement, le protocole est le suivant : supposons qu'Alice veuille envoyer 11,7 BTC a Bob. D'abord, Alice cherchera un ensemble d'UTXO disponibles qu'elle possede et qui totalisent au moins 11,7 BTC. De maniere realiste, Alice ne pourra pas obtenir exactement 11,7 BTC ; disons que le plus petit montant qu'elle peut obtenir est 6+4+2=12. Elle cree alors une transaction avec ces trois entrees et deux sorties. La premiere sortie sera de 11,7 BTC avec l'adresse de Bob comme proprietaire, et la seconde sortie sera le "change" restant de 0,3 BTC, dont le proprietaire est Alice elle-meme.
Mining
If we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized server's hard drive to keep track of the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks." The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (i.e. hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, "blockchain" that constantly updates to represent the latest state of the Bitcoin ledger.
The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:
- Check if the previous block referenced by the block exists and is valid.
- Check that the timestamp of the block is greater than that of the previous block and less than 2 hours into the future.
- Check that the proof of work on the block is valid.
- Let
S[0]be the state at the end of the previous block. - Suppose TX is the block's transaction list with n transactions. For all i in 0...n-1, set
S[i+1] = APPLY(S[i],TX[i]). If any application returns an error, exit and return false. - Return true, and register
S[n]as the state at the end of this block.
Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.
The one validity condition present in the above list that is not found in other systems is the requirement for "proof of work." The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately \(2^{187}\). The purpose of this is to make block creation computationally "hard," thereby preventing sybil attackers from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.
At the current target of \(\sim 2^{187}\), the network must make an average of \(\sim 2^{69}\) tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a "transaction fee." Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.
In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:
- Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good).
- Wait for the delivery of the product.
- Produce another transaction sending the same 100 BTC to himself.
- Try to convince the network that his transaction to himself was the one that came first.
Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it. At this point, the merchant will accept the payment as finalized and deliver the product. Since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof of work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack").
Mining
Si nous avions acces a un service centralise digne de confiance, ce systeme serait trivial a implementer ; il pourrait simplement etre code exactement comme decrit, en utilisant le disque dur d'un serveur centralise pour garder la trace de l'etat. Cependant, avec Bitcoin, nous essayons de construire un systeme monetaire decentralise, nous devrons donc combiner le systeme de transaction d'etat avec un systeme de consensus afin de nous assurer que tout le monde est d'accord sur l'ordre des transactions. Le processus de consensus decentralise de Bitcoin necessite que les noeuds du reseau tentent en permanence de produire des paquets de transactions appeles "blocs". Le reseau est cense produire environ un bloc toutes les dix minutes, chaque bloc contenant un horodatage, un nonce, une reference au (c'est-a-dire le hash du) bloc precedent et une liste de toutes les transactions ayant eu lieu depuis le bloc precedent.
Au fil du temps, cela cree une "blockchain" persistante et en croissance continue qui se met constamment a jour pour representer le dernier etat du registre Bitcoin. L'algorithme pour verifier si un bloc est valide, exprime dans ce paradigme, est le suivant :
- Verifier si le bloc precedent reference par le bloc existe et est valide.
- Verifier que l'horodatage du bloc est superieur a celui du bloc precedent et inferieur a 2 heures dans le futur.
- Verifier que la preuve de travail sur le bloc est valide.
- Soit S l'etat a la fin du bloc precedent.
- Supposons que TX est la liste de transactions du bloc avec n transactions. Pour tout i dans 0...n-1, definir S = APPLY(S,TX[i]). Si une application renvoie une erreur, quitter et renvoyer faux.
- Renvoyer vrai, et enregistrer S comme l'etat a la fin de ce bloc.
Essentiellement, chaque transaction dans le bloc doit fournir une transition d'etat valide depuis ce qui etait l'etat canonique avant l'execution de la transaction vers un nouvel etat. Notez que l'etat n'est encode dans le bloc d'aucune maniere ; c'est purement une abstraction a retenir par le noeud validant et ne peut etre (de maniere securisee) calcule pour n'importe quel bloc qu'en partant de l'etat genesis et en appliquant sequentiellement chaque transaction dans chaque bloc.
Le mineur est recompense pour son travail computationnel par des bitcoins nouvellement crees plus les frais de transaction. Le processus de minage fonctionne comme suit : les mineurs prennent l'en-tete du bloc et le hachent de maniere repetee avec differentes valeurs de nonce jusqu'a ce qu'ils trouvent un hash inferieur a un certain objectif de difficulte. Quand un mineur trouve un tel hash, il diffuse le bloc sur le reseau, et les autres noeuds verifient que le hash est valide et que toutes les transactions du bloc sont valides. L'objectif de difficulte est automatiquement ajuste par le protocole tous les 2016 blocs (environ deux semaines) pour s'assurer que les blocs sont produits a un rythme a peu pres constant.
Notez qu'a long terme, la securite de la blockchain depend du fait que les mineurs aient une incitation financiere a se comporter honnetement. Si un attaquant controle plus de 50% de la puissance de minage du reseau, il peut potentiellement executer une "attaque a 51%" en creant une blockchain alternative qui croit plus vite que la chaine honnete. Cependant, une telle attaque necessiterait d'enormes ressources computationnelles et aboutirait probablement a ce que les recompenses de minage de l'attaquant deviennent sans valeur a mesure que le reseau perdrait confiance dans l'integrite de la blockchain.
Merkle Trees
Merkle trees are a fundamental data structure used in Bitcoin blocks to enable efficient and secure verification of transaction inclusion. A Merkle tree is a binary tree of hashes where the leaf nodes contain hashes of individual transactions, and each interior node contains the hash of its two children, recursively building up to a single root hash that is stored in the block-header/" class="glossary-link" data-slug="block-header" title="block header">block header. This hierarchical structure allows anyone to verify that a specific transaction is included in a block by downloading only the Merkle branch—the chain of hashes from the transaction up to the root—rather than downloading all transactions in the block.
The efficiency gains are substantial: while a full Bitcoin node must store the entire blockchain (approximately 15GB as of 2013), a simplified payment verification (SPV) node only needs to download block headers containing Merkle roots, requiring just 4MB of data. To verify a transaction, an SPV node requests the Merkle branch from full nodes, which requires only \(O(\log n)\) data where \(n\) is the number of transactions in a block. This logarithmic scaling makes it feasible to run lightweight clients on mobile devices and low-resource environments.
Bitcoin's use of Merkle trees demonstrates a key principle: cryptographic structures can dramatically reduce the trust and resource requirements for participating in a decentralized network. This same principle underlies Ethereum's design, where Merkle trees are used not only for transactions but also for state and receipt storage, enabling even more sophisticated light client protocols.
Merkle Trees
Les arbres de Merkle sont une structure de donnees fondamentale utilisee dans les blocs Bitcoin pour permettre une verification efficace et securisee de l'inclusion des transactions. Un arbre de Merkle est un arbre binaire de hachages ou les noeuds feuilles contiennent les hachages des transactions individuelles, et chaque noeud interieur contient le hachage de ses deux enfants, construisant recursivement jusqu'a un seul hachage racine stocke dans l'en-tete du bloc. Cette structure hierarchique permet a quiconque de verifier qu'une transaction specifique est incluse dans un bloc en telechargeant uniquement la branche de Merkle — la chaine de hachages de la transaction jusqu'a la racine — plutot que de telecharger toutes les transactions du bloc.
Les gains d'efficacite sont substantiels : tandis qu'un noeud Bitcoin complet doit stocker l'integralite de la blockchain (environ 15 Go en 2013), un noeud de verification simplifiee des paiements (SPV) n'a besoin de telecharger que les en-tetes de blocs contenant les racines de Merkle, necessitant seulement 4 Mo de donnees. Pour verifier une transaction, un noeud SPV demande la branche de Merkle aux noeuds complets, ce qui ne necessite que O(log n) donnees ou n est le nombre de transactions dans un bloc. Cette mise a l'echelle logarithmique rend possible l'execution de clients legers sur des appareils mobiles et dans des environnements a faibles ressources.
L'utilisation des arbres de Merkle par Bitcoin demontre un principe cle : les structures cryptographiques peuvent reduire considerablement les exigences de confiance et de ressources pour participer a un reseau decentralise. Ce meme principe sous-tend la conception d'Ethereum, ou les arbres de Merkle sont utilises non seulement pour les transactions mais aussi pour le stockage de l'etat et des recus, permettant des protocoles de clients legers encore plus sophistiques.
Alternative Blockchain Applications
The success of Bitcoin's blockchain inspired numerous attempts to extend the concept beyond simple currency. Namecoin, launched in 2010, was one of the earliest examples—a decentralized name registration database built on a blockchain, allowing users to register names in a distributed namespace that no central authority could censor or revoke. Colored coins emerged as a way to represent alternative assets on the Bitcoin blockchain by "tagging" specific transaction outputs to represent ownership of real-world assets, company shares, or other cryptocurrencies. Metacoins and meta-protocols like Mastercoin (later Omni) layered additional functionality on top of Bitcoin by encoding extra data in Bitcoin transactions and building separate protocol rules on top.
However, all these approaches suffered from fundamental limitations imposed by Bitcoin's architecture. The Bitcoin scripting language is intentionally restricted—it cannot access blockchain state, lacks loops and complex control flow, and provides limited introspection into transaction values. Building sophisticated applications required awkward workarounds: encoding metadata in transaction fields never intended for that purpose, relying on off-chain infrastructure for complex logic, or accepting severe limitations on what the protocol could accomplish.
These constraints motivated the search for a more general-purpose blockchain platform. Rather than building yet another special-purpose protocol on top of Bitcoin's limited foundation, Ethereum takes a different approach: providing a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications with arbitrary rules for ownership, transaction formats, and state transition functions.
Alternative Blockchain Applications
Le succes de la blockchain de Bitcoin a inspire de nombreuses tentatives pour etendre le concept au-dela de la simple monnaie. Namecoin, lance en 2010, fut l'un des premiers exemples — une base de donnees d'enregistrement de noms decentralisee construite sur une blockchain, permettant aux utilisateurs d'enregistrer des noms dans un espace de noms distribue qu'aucune autorite centrale ne pouvait censurer ou revoquer. Les colored coins ont emerge comme un moyen de representer des actifs alternatifs sur la blockchain Bitcoin en "marquant" des sorties de transactions specifiques pour representer la propriete d'actifs du monde reel, d'actions d'entreprises ou d'autres cryptomonnaies. Les metacoins et meta-protocoles comme Mastercoin (plus tard Omni) ont ajoute des fonctionnalites supplementaires par-dessus Bitcoin en encodant des donnees supplementaires dans les transactions Bitcoin et en construisant des regles de protocole separees par-dessus.
Cependant, toutes ces approches souffraient de limitations fondamentales imposees par l'architecture de Bitcoin. Le langage de script de Bitcoin est intentionnellement restreint — il ne peut pas acceder a l'etat de la blockchain, manque de boucles et de flux de controle complexes, et offre une introspection limitee des valeurs de transaction. Construire des applications sophistiquees necessitait des solutions de contournement maladroites : encoder des metadonnees dans des champs de transaction jamais destines a cet usage, s'appuyer sur une infrastructure hors chaine pour la logique complexe, ou accepter de severes limitations sur ce que le protocole pouvait accomplir.
Ces contraintes ont motive la recherche d'une plateforme blockchain plus generaliste. Plutot que de construire encore un autre protocole a usage specifique par-dessus les fondations limitees de Bitcoin, Ethereum adopte une approche differente : fournir une blockchain avec un langage de programmation Turing-complet integre, permettant a quiconque d'ecrire des smart contracts et des applications decentralisees avec des regles arbitraires pour la propriete, les formats de transaction et les fonctions de transition d'etat.
Scripting
Bitcoin Script, the language used to define spending conditions for Bitcoin transactions, is intentionally designed with severe limitations. It is not Turing-complete—most notably, it lacks loops and complex control flow structures. The language operates as a simple stack-based execution environment where operations push and pop values, evaluate cryptographic conditions, and ultimately return true or false to determine whether a transaction is valid. While this simplicity provides security benefits and makes formal analysis easier, it also makes many types of applications impossible to implement.
These limitations fall into three main categories. First, the lack of Turing-completeness prevents implementing complex state machines, decision trees, or any algorithm requiring iteration. Second, value-blindness means that scripts cannot specify fine-grained control over withdrawal amounts—a UTXO can only be spent in its entirety, with change sent to a new output. A script cannot, for example, limit withdrawals to a maximum of X per day while leaving the remainder locked. Third, the lack of blockchain state awareness means that UTXO are either spent or unspent with no intermediate states, making multi-stage contracts impossible to implement purely on-chain.
These constraints make sophisticated applications like decentralized autonomous organizations, savings wallets with withdrawal limits, decentralized exchanges, or prediction markets either impossible or require awkward off-chain mechanisms. An advanced financial contract might require access to market data, the ability to maintain internal state across multiple transactions, and complex conditional logic—none of which Bitcoin Script can provide. Ethereum removes these limitations by providing a Turing-complete language with full access to blockchain state.
Scripting
Bitcoin Script, le langage utilise pour definir les conditions de depense des transactions Bitcoin, est intentionnellement concu avec des limitations severes. Il n'est pas Turing-complet — plus notablement, il manque de boucles et de structures de flux de controle complexes. Le langage fonctionne comme un environnement d'execution simple base sur une pile ou les operations poussent et retirent des valeurs, evaluent des conditions cryptographiques, et retournent finalement vrai ou faux pour determiner si une transaction est valide. Bien que cette simplicite offre des avantages de securite et facilite l'analyse formelle, elle rend egalement de nombreux types d'applications impossibles a implementer.
Ces limitations se repartissent en trois categories principales. Premierement, le manque de completude de Turing empeche d'implementer des machines d'etat complexes, des arbres de decision, ou tout algorithme necessitant une iteration. Deuxiemement, l'aveuglement aux valeurs signifie que les scripts ne peuvent pas specifier un controle fin sur les montants de retrait — un UTXO ne peut etre depense que dans sa totalite, avec la monnaie envoyee a une nouvelle sortie. Un script ne peut pas, par exemple, limiter les retraits a un maximum de X par jour tout en laissant le reste verrouille. Troisiemement, le manque de conscience de l'etat de la blockchain signifie que les UTXO sont soit depenses soit non depenses sans etats intermediaires, rendant les contrats multi-etapes impossibles a implementer purement on-chain.
Ces contraintes rendent les applications sophistiquees comme les organisations autonomes decentralisees, les portefeuilles d'epargne avec des limites de retrait, les echanges decentralises, ou les marches de prediction soit impossibles soit necessitant des mecanismes hors chaine maladroits. Un contrat financier avance pourrait necessiter l'acces a des donnees de marche, la capacite de maintenir un etat interne a travers plusieurs transactions, et une logique conditionnelle complexe — aucun de ces elements ne pouvant etre fourni par Bitcoin Script. Ethereum supprime ces limitations en fournissant un langage Turing-complet avec un acces complet a l'etat de la blockchain.
Ethereum
Ethereum's fundamental goal is to provide a blockchain with a built-in Turing-complete programming language that allows anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats, and state transition functions. Rather than designing a protocol for specific applications like currency, name registration, or asset trading, Ethereum provides a foundational layer—a blockchain-based distributed computing platform that developers can use to build any application they can imagine.
The architecture differs fundamentally from Bitcoin's UTXO model. Ethereum uses an account-based system where the blockchain state consists of a mapping from addresses to account objects. Each account has a balance, a transaction counter (nonce), and for contract accounts, associated code and storage. The platform includes a built-in Turing-complete programming language for writing contract code that executes in the Ethereum Virtual Machine (EVM), a stack-based execution environment that processes transactions and state transitions.
This generality enables a vast range of applications: alternative cryptocurrencies with custom issuance rules, financial derivatives and stablecoins, identity and reputation systems, decentralized file storage, decentralized autonomous organizations (DAOs), and much more. The whitepaper emphasizes that Ethereum is not optimized for any particular use case but instead provides the fundamental building blocks—accounts, transactions, a Turing-complete language, and gas-metered execution—that developers can combine to create whatever applications the ecosystem demands.
Ethereum
L'objectif fondamental d'Ethereum est de fournir une blockchain avec un langage de programmation Turing-complet integre qui permet a quiconque d'ecrire des smart contracts et des applications decentralisees ou ils peuvent creer leurs propres regles arbitraires pour la propriete, les formats de transaction et les fonctions de transition d'etat. Plutot que de concevoir un protocole pour des applications specifiques comme la monnaie, l'enregistrement de noms ou le commerce d'actifs, Ethereum fournit une couche fondamentale — une plateforme informatique distribuee basee sur la blockchain que les developpeurs peuvent utiliser pour construire toute application qu'ils peuvent imaginer.
L'architecture differe fondamentalement du modele UTXO de Bitcoin. Ethereum utilise un systeme base sur les comptes ou l'etat de la blockchain consiste en une correspondance des adresses vers des objets de compte. Chaque compte a un solde, un compteur de transactions (nonce), et pour les comptes de contrats, du code et du stockage associes. La plateforme inclut un langage de programmation Turing-complet integre pour ecrire du code de contrat qui s'execute dans la Machine Virtuelle Ethereum (EVM), un environnement d'execution base sur une pile qui traite les transactions et les transitions d'etat.
Cette generalite permet une vaste gamme d'applications : des cryptomonnaies alternatives avec des regles d'emission personnalisees, des derives financiers et des stablecoins, des systemes d'identite et de reputation, du stockage de fichiers decentralise, des organisations autonomes decentralisees (DAOs), et bien plus encore. Le whitepaper souligne qu'Ethereum n'est pas optimise pour un cas d'utilisation particulier mais fournit plutot les blocs de construction fondamentaux — comptes, transactions, un langage Turing-complet et une execution mesuree par le gas — que les developpeurs peuvent combiner pour creer les applications que l'ecosysteme exige.
Ethereum Accounts
In Ethereum, the state is made up of accounts, and there are two fundamental types. Externally owned accounts (EOAs) are controlled by private keys and have no associated code—they represent human users or external entities interacting with the blockchain. Contract accounts are controlled by their contract code and are activated when they receive a message or transaction. Both types share a common structure: every account has a nonce (a counter used to ensure each transaction can only be processed once), an ether balance, and for contracts specifically, contract code and persistent storage.
Ether is the primary internal cryptocurrency of Ethereum, serving as both a medium of value transfer and the fundamental unit for paying transaction fees (gas). Unlike Bitcoin's UTXO model where value is distributed across multiple unspent outputs, Ethereum accounts maintain a simple balance that increases when they receive ether and decreases when they send it. This account-based model simplifies many types of applications, particularly those requiring persistent state or complex access control, though it introduces different security considerations compared to Bitcoin's approach.
The distinction between EOAs and contract accounts is crucial to understanding Ethereum's operation. EOAs can initiate transactions by creating and signing messages with their private keys, paying gas fees to have their transactions included in blocks. Contract accounts cannot initiate transactions themselves but can send messages to other contracts in response to receiving a transaction or message, enabling complex chains of execution where a single external transaction triggers multiple contract-to-contract interactions.
Ethereum Accounts
Dans Ethereum, l'etat est constitue de comptes, et il existe deux types fondamentaux. Les comptes a propriete externe (EOAs) sont controles par des cles privees et n'ont pas de code associe — ils representent des utilisateurs humains ou des entites externes interagissant avec la blockchain. Les comptes de contrats sont controles par leur code de contrat et sont actives lorsqu'ils recoivent un message ou une transaction. Les deux types partagent une structure commune : chaque compte a un nonce (un compteur utilise pour s'assurer que chaque transaction ne peut etre traitee qu'une seule fois), un solde en ether, et pour les contrats specifiquement, du code de contrat et du stockage persistant.
L'ether est la cryptomonnaie interne principale d'Ethereum, servant a la fois de moyen de transfert de valeur et d'unite fondamentale pour payer les frais de transaction (gas). Contrairement au modele UTXO de Bitcoin ou la valeur est distribuee a travers plusieurs sorties non depensees, les comptes Ethereum maintiennent un solde simple qui augmente lorsqu'ils recoivent de l'ether et diminue lorsqu'ils en envoient. Ce modele base sur les comptes simplifie de nombreux types d'applications, en particulier celles necessitant un etat persistant ou un controle d'acces complexe, bien qu'il introduise des considerations de securite differentes par rapport a l'approche de Bitcoin.
La distinction entre les EOAs et les comptes de contrats est cruciale pour comprendre le fonctionnement d'Ethereum. Les EOAs peuvent initier des transactions en creant et signant des messages avec leurs cles privees, payant des frais de gas pour que leurs transactions soient incluses dans les blocs. Les comptes de contrats ne peuvent pas initier de transactions eux-memes mais peuvent envoyer des messages a d'autres contrats en reponse a la reception d'une transaction ou d'un message, permettant des chaines d'execution complexes ou une seule transaction externe declenche de multiples interactions de contrat a contrat.
Messages and Transactions
Transactions in Ethereum are signed data packages created by externally owned accounts and broadcast to the network. A transaction contains the recipient address, a cryptographic signature proving the sender's identity, the amount of ether to transfer, an optional data field (crucial for interacting with contracts), STARTGAS (the maximum number of computational steps the transaction is allowed to take), and GASPRICE (the fee per computational step the sender is willing to pay). Miners collect these transactions, validate them, execute them, and include them in blocks, receiving the gas fees as compensation.
Messages are conceptually similar to transactions but are produced by contracts rather than external actors. When a contract's code executes, it can send messages to other contracts—these internal messages contain the sender (the contract address), recipient, an amount of ether to transfer, an optional data payload, and a STARTGAS limit. Messages enable contract-to-contract communication, allowing complex applications to be built from multiple interacting contracts rather than monolithic programs.
The gas mechanism is crucial for preventing abuse: every computational step, storage operation, and data byte in a transaction consumes gas. If a transaction runs out of gas before completing, all state changes are reverted (except the gas payment to the miner), preventing infinite loops or excessive computation from grinding the network to a halt. The sender specifies both the total gas budget (STARTGAS) and the price they're willing to pay per unit (GASPRICE), and any unused gas is refunded after execution completes.
Messages and Transactions
Les transactions dans Ethereum sont des paquets de donnees signes crees par des comptes a propriete externe et diffuses sur le reseau. Une transaction contient l'adresse du destinataire, une signature cryptographique prouvant l'identite de l'expediteur, le montant d'ether a transferer, un champ de donnees optionnel (crucial pour interagir avec les contrats), STARTGAS (le nombre maximum d'etapes de calcul que la transaction est autorisee a effectuer), et GASPRICE (les frais par etape de calcul que l'expediteur est pret a payer). Les mineurs collectent ces transactions, les valident, les executent et les incluent dans des blocs, recevant les frais de gas comme compensation.
Les messages sont conceptuellement similaires aux transactions mais sont produits par des contrats plutot que par des acteurs externes. Lorsque le code d'un contrat s'execute, il peut envoyer des messages a d'autres contrats — ces messages internes contiennent l'expediteur (l'adresse du contrat), le destinataire, un montant d'ether a transferer, une charge utile de donnees optionnelle et une limite STARTGAS. Les messages permettent la communication de contrat a contrat, permettant de construire des applications complexes a partir de plusieurs contrats interagissant plutot que de programmes monolithiques.
Le mecanisme de gas est crucial pour prevenir les abus : chaque etape de calcul, operation de stockage et octet de donnees dans une transaction consomme du gas. Si une transaction epuise son gas avant de se terminer, tous les changements d'etat sont annules (sauf le paiement du gas au mineur), empechant les boucles infinies ou les calculs excessifs de paralyser le reseau. L'expediteur specifie a la fois le budget total de gas (STARTGAS) et le prix qu'il est pret a payer par unite (GASPRICE), et tout gas non utilise est rembourse apres l'execution.
Ethereum State Transition Function
The Ethereum state transition function APPLY(S,TX) - S' defines how a transaction transforms the blockchain state, and it follows a precise sequence of steps. First, the system checks transaction validity: verifying the signature is correct, confirming the nonce matches the sender's account nonce, and ensuring the sender has sufficient balance to pay the upfront cost (STARTGAS × GASPRICE plus the value being sent). If any check fails, the transaction is rejected before execution begins. If valid, the transaction fee is deducted from the sender's account, the sender's nonce is incremented, and an initial gas counter is set to STARTGAS minus a per-byte fee for the transaction data.
Next, the system transfers the specified ether value from the sender to the recipient. If the recipient is an externally owned account, this completes the transaction. If the recipient is a contract account, the contract's code runs in the Ethereum Virtual Machine, consuming gas for each operation until either the code completes successfully, the code explicitly halts, or the gas runs out. During execution, the contract can read and modify its storage, send messages to other contracts, and create new contracts.
Finally, if the value transfer failed (insufficient balance) or code execution failed (running out of gas or hitting an error), all state changes are reverted—except that the sender still pays gas fees to the miner for the computation performed. If execution succeeded, the remaining gas is refunded to the sender, and the gas that was consumed is sent to the miner as a fee. This mechanism ensures that miners are compensated for computation while preventing runaway execution from consuming unbounded resources.
Ethereum State Transition Function
La fonction de transition d'etat d'Ethereum APPLY(S,TX) - S' definit comment une transaction transforme l'etat de la blockchain, et elle suit une sequence precise d'etapes. Premierement, le systeme verifie la validite de la transaction : verifiant que la signature est correcte, confirmant que le nonce correspond au nonce du compte de l'expediteur, et s'assurant que l'expediteur dispose d'un solde suffisant pour payer le cout initial (STARTGAS x GASPRICE plus la valeur envoyee). Si une verification echoue, la transaction est rejetee avant le debut de l'execution. Si elle est valide, les frais de transaction sont deduits du compte de l'expediteur, le nonce de l'expediteur est incremente, et un compteur de gas initial est defini a STARTGAS moins des frais par octet pour les donnees de la transaction.
Ensuite, le systeme transfere la valeur en ether specifiee de l'expediteur au destinataire. Si le destinataire est un compte a propriete externe, cela complete la transaction. Si le destinataire est un compte de contrat, le code du contrat s'execute dans la Machine Virtuelle Ethereum, consommant du gas pour chaque operation jusqu'a ce que le code se termine avec succes, que le code s'arrete explicitement, ou que le gas soit epuise. Pendant l'execution, le contrat peut lire et modifier son stockage, envoyer des messages a d'autres contrats et creer de nouveaux contrats.
Enfin, si le transfert de valeur a echoue (solde insuffisant) ou si l'execution du code a echoue (epuisement du gas ou erreur), tous les changements d'etat sont annules — sauf que l'expediteur paie toujours les frais de gas au mineur pour le calcul effectue. Si l'execution a reussi, le gas restant est rembourse a l'expediteur, et le gas consomme est envoye au mineur comme frais. Ce mecanisme garantit que les mineurs sont compenses pour le calcul tout en empechant les executions incontroles de consommer des ressources illimitees.
Code Execution
The Ethereum Virtual Machine (EVM) is the runtime environment where contract code executes—a low-level, stack-based virtual machine similar in concept to the Java Virtual Machine or WebAssembly. Contract code is stored as a sequence of bytes, where each byte represents an operation (opcode) that the EVM can execute. The execution model is deliberately simple and deterministic: every node running the EVM with the same input state and transaction must arrive at the same output state, ensuring consensus across the network.
The EVM provides three distinct types of storage for computation. The stack is a last-in-first-out (LIFO) structure limited to 1024 elements, used for immediate operation values. Memory is an infinitely expandable byte array that persists only for the duration of a single message call and is reset between executions. Storage is the persistent key-value store permanently associated with each account/" class="glossary-link" data-slug="contract-account" title="contract account">contract account, where contracts maintain their long-term state across transactions. These storage types are priced differently in gas—stack and memory operations are cheap, while storage operations are expensive to prevent blockchain bloat.
During execution, contract code has access to crucial context: it can read the message sender's address, the amount of ether sent, the data payload provided by the caller, and block-level properties like the current block number, timestamp, and miner address. The code can return an output byte array to the caller and can send messages to other contracts or create new contracts. This execution model is Turing-complete—loops and complex control flow are possible—but the gas mechanism ensures that all computation terminates in bounded time, solving the halting problem economically rather than through language restrictions.
Code Execution
La Machine Virtuelle Ethereum (EVM) est l'environnement d'execution ou le code des contrats s'execute — une machine virtuelle de bas niveau basee sur une pile, similaire en concept a la Machine Virtuelle Java ou WebAssembly. Le code des contrats est stocke sous forme d'une sequence d'octets, ou chaque octet represente une operation (opcode) que l'EVM peut executer. Le modele d'execution est deliberement simple et deterministe : chaque noeud executant l'EVM avec le meme etat d'entree et la meme transaction doit arriver au meme etat de sortie, assurant le consensus a travers le reseau.
L'EVM fournit trois types distincts de stockage pour le calcul. La pile est une structure dernier entre, premier sorti (LIFO) limitee a 1024 elements, utilisee pour les valeurs d'operation immediates. La memoire est un tableau d'octets extensible a l'infini qui persiste uniquement pour la duree d'un seul appel de message et est reinitialise entre les executions. Le stockage est le magasin cle-valeur persistant associe de maniere permanente a chaque compte de contrat">compte de contrat, ou les contrats maintiennent leur etat a long terme a travers les transactions. Ces types de stockage sont tarifes differemment en gas — les operations sur la pile et la memoire sont bon marche, tandis que les operations de stockage sont couteuses pour prevenir le gonflement de la blockchain.
Pendant l'execution, le code du contrat a acces a un contexte crucial : il peut lire l'adresse de l'expediteur du message, le montant d'ether envoye, la charge utile de donnees fournie par l'appelant, et les proprietes au niveau du bloc comme le numero de bloc actuel, l'horodatage et l'adresse du mineur. Le code peut retourner un tableau d'octets de sortie a l'appelant et peut envoyer des messages a d'autres contrats ou creer de nouveaux contrats. Ce modele d'execution est Turing-complet — les boucles et le flux de controle complexe sont possibles — mais le mecanisme de gas garantit que tout calcul se termine en temps borne, resolvant le probleme de l'arret de maniere economique plutot que par des restrictions de langage.
Blockchain and Mining
The Ethereum blockchain is fundamentally similar to Bitcoin's, serving as a database containing every transaction ever executed. However, while Bitcoin stores only a transaction list, Ethereum stores both the transaction list and the most recent state. Each block in Ethereum contains the previous block's hash, a state root (the root hash of the Patricia trie">Merkle Patricia trie representing the entire state), a transaction root, a receipt root (storing data from transaction execution), along with difficulty, timestamp, and nonce values. The state itself is a large Merkle Patricia trie mapping addresses to account objects, where each account has a balance, nonce, code (if present), and storage.
Ethereum uses a modified version of the GHOST (Greedy Heaviest Observed Subtree) protocol to address security issues that arise from fast block times. In traditional longest-chain protocols, fast blocks lead to high stale rates, reducing network security and increasing centralization risks as large miners waste less computation on stales. GHOST includes stale blocks (called "uncles" in Ethereum) in the calculation of which chain is longest, and provides partial rewards to uncle blocks, incentivizing miners to reference them. This allows Ethereum to maintain a target block time of approximately 12 seconds while preserving network security.
The mining algorithm works similarly to Bitcoin's proof-of-work, requiring miners to find a nonce such that the hash of the block is below a certain difficulty target. However, Ethereum's memory-hard mining algorithm (Ethash) is designed to be ASIC-resistant, promoting a more decentralized mining ecosystem. The difficulty adjusts dynamically based on block times to maintain the ~12 second target, ensuring consistent block production while the GHOST protocol provides security guarantees despite the faster block times compared to Bitcoin's 10-minute average.
Blockchain and Mining
La blockchain Ethereum est fondamentalement similaire a celle de Bitcoin, servant de base de donnees contenant chaque transaction jamais executee. Cependant, alors que Bitcoin ne stocke qu'une liste de transactions, Ethereum stocke a la fois la liste des transactions et l'etat le plus recent. Chaque bloc dans Ethereum contient le hachage du bloc precedent, une racine d'etat (le hachage racine du trie Patricia de Merkle representant l'etat entier), une racine de transaction, une racine de recu (stockant les donnees de l'execution des transactions), ainsi que des valeurs de difficulte, d'horodatage et de nonce. L'etat lui-meme est un grand trie Patricia de Merkle faisant correspondre les adresses aux objets de compte, ou chaque compte a un solde, un nonce, du code (si present) et du stockage.
Ethereum utilise une version modifiee du protocole GHOST (Greedy Heaviest Observed Subtree) pour traiter les problemes de securite qui surviennent avec des temps de bloc rapides. Dans les protocoles traditionnels de chaine la plus longue, des blocs rapides conduisent a des taux de blocs perimes eleves, reduisant la securite du reseau et augmentant les risques de centralisation car les grands mineurs gaspillent moins de calcul sur les blocs perimes. GHOST inclut les blocs perimes (appeles "oncles" dans Ethereum) dans le calcul de la chaine la plus longue, et fournit des recompenses partielles aux blocs oncles, incitant les mineurs a les referencer. Cela permet a Ethereum de maintenir un temps de bloc cible d'environ 12 secondes tout en preservant la securite du reseau.
L'algorithme de minage fonctionne de maniere similaire a la preuve de travail de Bitcoin, exigeant des mineurs qu'ils trouvent un nonce tel que le hachage du bloc soit inferieur a un certain objectif de difficulte. Cependant, l'algorithme de minage a forte intensite memoire d'Ethereum (Ethash) est concu pour etre resistant aux ASIC, favorisant un ecosysteme de minage plus decentralise. La difficulte s'ajuste dynamiquement en fonction des temps de bloc pour maintenir la cible d'environ 12 secondes, assurant une production de blocs constante tandis que le protocole GHOST fournit des garanties de securite malgre les temps de bloc plus rapides par rapport a la moyenne de 10 minutes de Bitcoin.
Applications
The applications that can be built on Ethereum fall into three broad categories. The first category is financial applications, providing users with more powerful ways to manage and enter contracts involving their money. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets with withdrawal limits, wills that distribute funds automatically, and even employment contracts that calculate payment based on verified work completion. These applications leverage Ethereum's programmability to create complex financial instruments that would be impossible or extremely difficult to implement in traditional systems or even on Bitcoin.
The second category is semi-financial applications, where money is involved but there is also a substantial non-monetary component to what is being done. A perfect example is self-enforcing bounties for solutions to computational problems. Someone could post a computational problem along with a reward, and the contract could automatically verify submitted solutions and pay out the bounty to the first correct answer. This category bridges pure finance and other domains, using economic incentives to solve problems or coordinate behavior.
The third category is applications that have nothing to do with money at all, such as online voting and decentralized governance systems. These non-financial applications demonstrate Ethereum's flexibility as a general-purpose platform. Examples include decentralized domain name systems like Namecoin, reputation systems, decentralized file storage, and organizational governance tools. Of all these application types, token systems have emerged as the most common and fundamental, serving as building blocks for many other applications.
Applications
Les applications qui peuvent etre construites sur Ethereum se repartissent en trois grandes categories. La premiere categorie est celle des applications financieres, fournissant aux utilisateurs des moyens plus puissants de gerer et de conclure des contrats impliquant leur argent. Cela inclut les sous-monnaies, les derives financiers, les contrats de couverture, les portefeuilles d'epargne avec des limites de retrait, les testaments qui distribuent automatiquement les fonds, et meme les contrats de travail qui calculent le paiement en fonction de l'achevement verifie du travail. Ces applications tirent parti de la programmabilite d'Ethereum pour creer des instruments financiers complexes qui seraient impossibles ou extremement difficiles a implementer dans les systemes traditionnels ou meme sur Bitcoin.
La deuxieme categorie est celle des applications semi-financieres, ou l'argent est implique mais il y a aussi une composante non monetaire substantielle dans ce qui est realise. Un exemple parfait est celui des primes auto-executoires pour les solutions a des problemes de calcul. Quelqu'un pourrait poster un probleme de calcul accompagne d'une recompense, et le contrat pourrait automatiquement verifier les solutions soumises et payer la prime a la premiere reponse correcte. Cette categorie fait le pont entre la finance pure et d'autres domaines, utilisant des incitations economiques pour resoudre des problemes ou coordonner les comportements.
La troisieme categorie est celle des applications qui n'ont rien a voir avec l'argent, comme le vote en ligne et les systemes de gouvernance decentralises. Ces applications non financieres demontrent la flexibilite d'Ethereum en tant que plateforme generaliste. Les exemples incluent les systemes de noms de domaine decentralises comme Namecoin, les systemes de reputation, le stockage de fichiers decentralise et les outils de gouvernance organisationnelle. Parmi tous ces types d'applications, les systemes de tokens ont emerge comme les plus courants et fondamentaux, servant de blocs de construction pour de nombreuses autres applications.
Token Systems
Token systems are surprisingly straightforward to implement on Ethereum, despite being one of the most powerful and common applications. At their core, token systems are simply a database with a single operation: subtract X units from account A and add X units to account B, with the condition that A had at least X units before the transaction and the transaction is authorized by A. The implementation requires maintaining a mapping of addresses to balances and providing a transfer function that performs the appropriate checks before moving tokens between accounts.
The contract code for a basic token system is remarkably simple and can be written in just a few lines. It consists of a data structure mapping addresses to balances, an initialization function that assigns initial token supply, and a transfer function that checks the sender's balance and authorization before executing the transfer. This simplicity stands in stark contrast to the complexity required to implement similar systems on Bitcoin, which would require significant workarounds and limitations due to Bitcoin's restricted scripting capabilities.
Tokens on Ethereum can represent virtually anything of value. They might represent sub-currencies with their own monetary policies, financial derivatives tracking external assets, company shares with dividend rights, loyalty points in customer programs, commodities like gold or oil, or even representations of physical property. The programmability of Ethereum allows these tokens to have arbitrary rules governing their behavior, such as transfer restrictions, automatic burning mechanisms, dividend distributions, or governance rights. This flexibility has made token systems the foundational building block for much of the Ethereum ecosystem.
Token Systems
Les systemes de tokens sont etonnamment simples a implementer sur Ethereum, bien qu'ils soient l'une des applications les plus puissantes et les plus courantes. A leur base, les systemes de tokens sont simplement une base de donnees avec une seule operation : soustraire X unites du compte A et ajouter X unites au compte B, a condition que A ait eu au moins X unites avant la transaction et que la transaction soit autorisee par A. L'implementation necessite de maintenir une correspondance des adresses aux soldes et de fournir une fonction de transfert qui effectue les verifications appropriees avant de deplacer les tokens entre les comptes.
Le code du contrat pour un systeme de tokens basique est remarquablement simple et peut etre ecrit en quelques lignes seulement. Il consiste en une structure de donnees faisant correspondre les adresses aux soldes, une fonction d'initialisation qui attribue l'offre initiale de tokens, et une fonction de transfert qui verifie le solde et l'autorisation de l'expediteur avant d'executer le transfert. Cette simplicite contraste fortement avec la complexite requise pour implementer des systemes similaires sur Bitcoin, qui necessiteraient des solutions de contournement et des limitations significatives en raison des capacites de script restreintes de Bitcoin.
Les tokens sur Ethereum peuvent representer virtuellement n'importe quoi de valeur. Ils peuvent representer des sous-monnaies avec leurs propres politiques monetaires, des derives financiers suivant des actifs externes, des actions d'entreprise avec des droits a dividendes, des points de fidelite dans des programmes clients, des matieres premieres comme l'or ou le petrole, ou meme des representations de propriete physique. La programmabilite d'Ethereum permet a ces tokens d'avoir des regles arbitraires gouvernant leur comportement, telles que des restrictions de transfert, des mecanismes de destruction automatique, des distributions de dividendes ou des droits de gouvernance. Cette flexibilite a fait des systemes de tokens le bloc de construction fondamental d'une grande partie de l'ecosysteme Ethereum.
Financial Derivatives and Stable-Value Currencies
Financial derivatives represent one of the most fundamental and important applications of Ethereum smart contracts. A simple hedging contract demonstrates the basic mechanism: party A deposits a certain amount of ether worth \(1000, party B deposits an equivalent amount, and the contract records the USD value of ether at that moment using a data feed. After 30 days, the contract recalculates the value and sends ether worth \)1000 to A and the remainder to B. If the price of ether has risen, A receives fewer ether but maintains $1000 value; if it has fallen, A receives more ether to maintain that value. This allows A to hedge against volatility while B speculates on price movements.
The implementation of such contracts requires access to external data through oracle contracts or data feeds. These oracles provide price information, weather data, or other real-world information that contracts need to execute properly. While oracles introduce a trust dependency, they can be designed with redundancy and cryptoeconomic incentives to provide reliable data. The contract itself simply queries the oracle, performs calculations based on that data, and distributes funds according to its programmed logic.
Stablecoins and more complex financial instruments can be built using similar mechanisms. A stablecoin contract might maintain a reserve of ether and issue tokens pegged to a fiat currency, automatically adjusting supply or collateral requirements based on price feeds. Options contracts, futures, swaps, and other derivatives that would normally require complex legal frameworks and trusted intermediaries can instead be encoded as self-executing smart contracts. This programmable finance infrastructure enables sophisticated financial engineering while maintaining the transparency and security guarantees of blockchain technology.
Financial Derivatives and Stable-Value Currencies
Les derives financiers representent l'une des applications les plus fondamentales et importantes des smart contracts Ethereum. Un simple contrat de couverture demontre le mecanisme de base : la partie A depose un certain montant d'ether d'une valeur de 1000 \(, la partie B depose un montant equivalent, et le contrat enregistre la valeur en USD de l'ether a ce moment en utilisant un flux de donnees. Apres 30 jours, le contrat recalcule la valeur et envoie de l'ether d'une valeur de 1000 \) a A et le reste a B. Si le prix de l'ether a augmente, A recoit moins d'ether mais maintient une valeur de 1000 $ ; s'il a baisse, A recoit plus d'ether pour maintenir cette valeur. Cela permet a A de se couvrir contre la volatilite tandis que B specule sur les mouvements de prix.
L'implementation de tels contrats necessite l'acces a des donnees externes via des contrats oracle ou des flux de donnees. Ces oracles fournissent des informations sur les prix, des donnees meteorologiques ou d'autres informations du monde reel dont les contrats ont besoin pour s'executer correctement. Bien que les oracles introduisent une dependance de confiance, ils peuvent etre concus avec de la redondance et des incitations cryptoeconomiques pour fournir des donnees fiables. Le contrat lui-meme interroge simplement l'oracle, effectue des calculs bases sur ces donnees et distribue les fonds selon sa logique programmee.
Les stablecoins et les instruments financiers plus complexes peuvent etre construits en utilisant des mecanismes similaires. Un contrat de stablecoin pourrait maintenir une reserve d'ether et emettre des tokens adosses a une monnaie fiduciaire, ajustant automatiquement l'offre ou les exigences de collateral en fonction des flux de prix. Les contrats d'options, de futures, de swaps et d'autres derives qui necessiteraient normalement des cadres juridiques complexes et des intermediaires de confiance peuvent plutot etre encodes comme des smart contracts auto-executoires. Cette infrastructure de finance programmable permet une ingenierie financiere sophistiquee tout en maintenant les garanties de transparence et de securite de la technologie blockchain.
Identity and Reputation Systems
A name registration system similar to Namecoin is trivially implementable on Ethereum and serves as the simplest example of an identity system. The contract maintains a database with a key-value table mapping names to associated data (such as IP addresses, public keys, or other information). Anyone can register a name by sending a transaction to the contract along with a small registration fee, provided that name is not already taken. The owner can update the associated data at any time, and names can be made transferable or permanent according to the rules encoded in the contract.
More advanced identity systems can be built on this foundation to include reputation scores, web of trust relationships, and decentralized identity verification. For example, a contract could maintain reputation scores based on verified transactions, peer ratings, or completion of tasks. These scores would be publicly visible and cryptographically tied to specific addresses, creating a portable reputation that follows users across applications. Web of trust systems could allow users to vouch for others' identities, building social graphs that help distinguish legitimate users from bad actors.
Such identity and reputation systems become particularly powerful when integrated with other applications. A marketplace could require minimum reputation scores for sellers, a loan platform could adjust interest rates based on borrower reputation, or a social network could use web of trust to filter spam and fraudulent content. By providing a shared infrastructure for identity that any application can query, Ethereum enables a new class of trust-based applications that don't rely on centralized identity providers or proprietary reputation systems.
Identity and Reputation Systems
Un systeme d'enregistrement de noms similaire a Namecoin est trivialement implementable sur Ethereum et sert d'exemple le plus simple d'un systeme d'identite. Le contrat maintient une base de donnees avec une table cle-valeur faisant correspondre les noms aux donnees associees (comme les adresses IP, les cles publiques ou d'autres informations). N'importe qui peut enregistrer un nom en envoyant une transaction au contrat accompagnee de frais d'enregistrement modestes, a condition que ce nom ne soit pas deja pris. Le proprietaire peut mettre a jour les donnees associees a tout moment, et les noms peuvent etre rendus transferables ou permanents selon les regles encodees dans le contrat.
Des systemes d'identite plus avances peuvent etre construits sur cette base pour inclure des scores de reputation, des relations de reseau de confiance et une verification d'identite decentralisee. Par exemple, un contrat pourrait maintenir des scores de reputation bases sur des transactions verifiees, des evaluations par les pairs ou l'accomplissement de taches. Ces scores seraient publiquement visibles et cryptographiquement lies a des adresses specifiques, creant une reputation portable qui suit les utilisateurs a travers les applications. Les systemes de reseau de confiance pourraient permettre aux utilisateurs de se porter garants de l'identite des autres, construisant des graphes sociaux qui aident a distinguer les utilisateurs legitimes des acteurs malveillants.
De tels systemes d'identite et de reputation deviennent particulierement puissants lorsqu'ils sont integres avec d'autres applications. Une place de marche pourrait exiger des scores de reputation minimums pour les vendeurs, une plateforme de pret pourrait ajuster les taux d'interet en fonction de la reputation de l'emprunteur, ou un reseau social pourrait utiliser le reseau de confiance pour filtrer le spam et le contenu frauduleux. En fournissant une infrastructure partagee pour l'identite que toute application peut interroger, Ethereum permet une nouvelle classe d'applications basees sur la confiance qui ne reposent pas sur des fournisseurs d'identite centralises ou des systemes de reputation proprietaires.
Decentralized File Storage
Decentralized file storage can be implemented through Ethereum contracts that coordinate between users who need storage and providers who offer it. In a "decentralized Dropbox" model, users would pay a monthly fee to upload files, with the contract distributing payments to storage providers who prove they are actually storing the data. The proof mechanism works through periodic cryptographic challenges: the contract randomly selects portions of files and asks providers to supply Merkle tree proofs demonstrating they possess that data. Providers who fail challenges or go offline would lose their deposits and future payment stream.
This approach offers several advantages over centralized storage. Merkle tree proofs enable efficient verification—users and the contract can confirm file availability without downloading entire files. The system naturally distributes files across multiple independent providers, creating redundancy without requiring explicit replication protocols. Economic incentives align provider behavior with user needs: providers earn money by reliably storing data and lose money if they fail to do so. This eliminates the trust requirement inherent in centralized storage solutions.
Storage costs in such a system can potentially be lower than centralized alternatives for several reasons. The elimination of monopoly pricing allows market competition to drive costs down to near the actual cost of storage. Implicit redundancy from multiple users storing similar files can reduce total storage requirements. There's no need for expensive data center infrastructure or corporate overhead. However, challenges remain around payment mechanisms, ensuring adequate provider participation, and managing the tradeoff between redundancy and cost. Despite these challenges, decentralized storage demonstrates how Ethereum can coordinate complex multi-party interactions through economic incentives alone.
Decentralized File Storage
Le stockage de fichiers decentralise peut etre implemente via des contrats Ethereum qui coordonnent entre les utilisateurs ayant besoin de stockage et les fournisseurs qui l'offrent. Dans un modele de "Dropbox decentralise", les utilisateurs paieraient des frais mensuels pour telecharger des fichiers, le contrat distribuant les paiements aux fournisseurs de stockage qui prouvent qu'ils stockent reellement les donnees. Le mecanisme de preuve fonctionne par des defis cryptographiques periodiques : le contrat selectionne aleatoirement des portions de fichiers et demande aux fournisseurs de fournir des preuves d'arbre de Merkle demontrant qu'ils possedent ces donnees. Les fournisseurs qui echouent aux defis ou se deconnectent perdraient leurs depots et leur flux de paiement futur.
Cette approche offre plusieurs avantages par rapport au stockage centralise. Les preuves d'arbre de Merkle permettent une verification efficace — les utilisateurs et le contrat peuvent confirmer la disponibilite des fichiers sans telecharger des fichiers entiers. Le systeme distribue naturellement les fichiers a travers plusieurs fournisseurs independants, creant de la redondance sans necessiter de protocoles de replication explicites. Les incitations economiques alignent le comportement des fournisseurs avec les besoins des utilisateurs : les fournisseurs gagnent de l'argent en stockant les donnees de maniere fiable et en perdent s'ils ne le font pas. Cela elimine l'exigence de confiance inherente aux solutions de stockage centralisees.
Les couts de stockage dans un tel systeme peuvent potentiellement etre inferieurs a ceux des alternatives centralisees pour plusieurs raisons. L'elimination de la tarification monopolistique permet a la concurrence du marche de ramener les couts pres du cout reel du stockage. La redondance implicite de plusieurs utilisateurs stockant des fichiers similaires peut reduire les besoins totaux de stockage. Il n'y a pas besoin d'infrastructure de centre de donnees couteuse ou de frais generaux d'entreprise. Cependant, des defis subsistent concernant les mecanismes de paiement, l'assurance d'une participation adequate des fournisseurs et la gestion du compromis entre redondance et cout. Malgre ces defis, le stockage decentralise demontre comment Ethereum peut coordonner des interactions complexes multi-parties uniquement par des incitations economiques.
Decentralized Autonomous Organizations
A Decentralized Autonomous Organization (DAO) is a virtual entity that has a set of members or shareholders who collectively have the right to spend the entity's funds and modify its code. A typical DAO operates with a simple rule: 67% of members are needed to make spending decisions or modify the organization's code. Members can submit proposals, vote on them, and if a proposal receives sufficient support, the contract automatically executes the decision. Membership shares can be transferable, allowing a liquid market for DAO participation, and different classes of shares can have different voting rights or economic claims.
The simplest DAO design is a self-modifying contract that maintains a list of members and requires a 2/3 majority vote to change any aspect of the contract, including its own voting rules. Members would submit code changes as transactions, other members would vote, and upon reaching the threshold, the contract would update itself. More sophisticated designs might include delegated voting systems where members can assign their voting power to representatives, or liquid democracy where votes can be delegated but reclaimed at any time for important decisions.
DAOs can serve various purposes beyond simple fund management. A DAO could function as a decentralized corporation, hiring contractors, purchasing services, and distributing profits to shareholders—all governed by smart contract code rather than traditional legal structures. It could operate as a decentralized investment fund, with members voting on which projects to fund. It could manage a commons resource, with stakeholders voting on allocation rules. The key insight is that by encoding governance rules in transparent, immutable code and tying them to economic stake, DAOs can coordinate group decisions without requiring traditional hierarchical management or legal enforcement.
Decentralized Autonomous Organizations
Une Organisation Autonome Decentralisee (DAO) est une entite virtuelle qui possede un ensemble de membres ou d'actionnaires qui ont collectivement le droit de depenser les fonds de l'entite et de modifier son code. Une DAO typique fonctionne avec une regle simple : 67% des membres sont necessaires pour prendre des decisions de depense ou modifier le code de l'organisation. Les membres peuvent soumettre des propositions, voter dessus, et si une proposition recoit un soutien suffisant, le contrat execute automatiquement la decision. Les parts de membres peuvent etre transferables, permettant un marche liquide pour la participation a la DAO, et differentes classes de parts peuvent avoir differents droits de vote ou revendications economiques.
La conception de DAO la plus simple est un contrat auto-modifiable qui maintient une liste de membres et necessite un vote a majorite des 2/3 pour modifier tout aspect du contrat, y compris ses propres regles de vote. Les membres soumettraient des modifications de code sous forme de transactions, les autres membres voteraient, et une fois le seuil atteint, le contrat se mettrait a jour. Des conceptions plus sophistiquees pourraient inclure des systemes de vote delegue ou les membres peuvent attribuer leur pouvoir de vote a des representants, ou une democratie liquide ou les votes peuvent etre delegues mais recuperes a tout moment pour les decisions importantes.
Les DAOs peuvent servir a divers objectifs au-dela de la simple gestion de fonds. Une DAO pourrait fonctionner comme une entreprise decentralisee, embauchant des prestataires, achetant des services et distribuant des benefices aux actionnaires — le tout gouverne par du code de smart contract plutot que par des structures juridiques traditionnelles. Elle pourrait fonctionner comme un fonds d'investissement decentralise, avec des membres votant sur les projets a financer. Elle pourrait gerer une ressource commune, avec les parties prenantes votant sur les regles d'allocation. L'insight cle est qu'en encodant les regles de gouvernance dans du code transparent et immuable et en les liant a un enjeu economique, les DAOs peuvent coordonner les decisions de groupe sans necessiter de gestion hierarchique traditionnelle ou d'application legale.
Further Applications
Beyond the major categories already discussed, Ethereum enables numerous other applications. Savings wallets with sophisticated security features can impose daily withdrawal limits while providing emergency keys for recovery, protecting users from theft while maintaining ultimate control. Crop insurance contracts can automatically pay farmers based on weather data feeds, eliminating claims processing and reducing administrative overhead. Peer-to-peer gambling applications can operate without any trusted intermediary, with smart contracts holding stakes and automatically paying winners based on verifiable random numbers or real-world event data.
On-chain prediction markets allow users to bet on future events, creating powerful forecasting mechanisms through the wisdom of crowds. These can be augmented with SchellingCoin-style protocols to create decentralized oracles: participants independently report data (like election results or weather conditions), and those whose reports match the majority receive rewards while outliers are penalized. This cryptoeconomic approach incentivizes honest reporting and can provide reliable real-world data to other contracts without requiring trust in any single oracle provider.
Multi-signature wallets represent another important application, enabling shared control of funds between multiple parties. A 2-of-3 multi-sig wallet might require any two of three designated parties to approve a transaction before funds can be spent, useful for escrow arrangements, corporate treasuries, or personal security. Decentralized marketplaces can combine identity systems, reputation scores, escrow contracts, and dispute resolution mechanisms to enable peer-to-peer commerce without centralized platforms. Each of these applications demonstrates how Ethereum's programmability enables new trust models and organizational structures.
Further Applications
Au-dela des grandes categories deja discutees, Ethereum permet de nombreuses autres applications. Les portefeuilles d'epargne avec des fonctionnalites de securite sophistiquees peuvent imposer des limites de retrait quotidiennes tout en fournissant des cles d'urgence pour la recuperation, protegeant les utilisateurs contre le vol tout en maintenant le controle ultime. Les contrats d'assurance recolte peuvent automatiquement payer les agriculteurs sur la base de flux de donnees meteorologiques, eliminant le traitement des reclamations et reduisant les frais administratifs. Les applications de jeux d'argent pair-a-pair peuvent fonctionner sans aucun intermediaire de confiance, les smart contracts detenant les mises et payant automatiquement les gagnants sur la base de nombres aleatoires verifiables ou de donnees d'evenements du monde reel.
Les marches de prediction on-chain permettent aux utilisateurs de parier sur des evenements futurs, creant de puissants mecanismes de prevision par la sagesse des foules. Ceux-ci peuvent etre augmentes avec des protocoles de type SchellingCoin pour creer des oracles decentralises : les participants rapportent independamment des donnees (comme les resultats d'elections ou les conditions meteorologiques), et ceux dont les rapports correspondent a la majorite recoivent des recompenses tandis que les valeurs aberrantes sont penalisees. Cette approche cryptoeconomique incite au reportage honnete et peut fournir des donnees fiables du monde reel a d'autres contrats sans necessiter de confiance en un seul fournisseur d'oracle.
Les portefeuilles multi-signatures representent une autre application importante, permettant le controle partage de fonds entre plusieurs parties. Un portefeuille multi-sig 2-sur-3 pourrait necessiter que deux des trois parties designees approuvent une transaction avant que les fonds puissent etre depenses, utile pour les arrangements d'entiercement, les tresoreries d'entreprise ou la securite personnelle. Les places de marche decentralisees peuvent combiner des systemes d'identite, des scores de reputation, des contrats d'entiercement et des mecanismes de resolution des litiges pour permettre le commerce pair-a-pair sans plateformes centralisees. Chacune de ces applications demontre comment la programmabilite d'Ethereum permet de nouveaux modeles de confiance et de nouvelles structures organisationnelles.
Miscellanea And Concerns
Ethereum's implementation of the modified GHOST protocol includes specific rules for uncle inclusion and rewards. Uncles must be direct children of the current block's ancestor (between 2 and 7 generations back), must be valid block headers, must be distinct from previous uncles, and must not be direct ancestors of the current block. Uncle blocks receive 87.5% of the standard block reward, while the including block receives an additional 3.125% per uncle included (up to two uncles). This incentive structure encourages miners to reference stale blocks they observe, strengthening network security while rewarding miners who experienced temporary bad luck with network propagation.
The transaction-fee/" class="glossary-link" data-slug="transaction-fee" title="fee">fee system is based on the concept of "gas," where every computational operation has a fixed gas cost. For example, a multiplication operation costs 5 gas, a SHA256 hash costs 20 gas, and every transaction has a base cost of 21,000 gas. Users specify both a gas limit (maximum gas they're willing to consume) and a gas price (how much ether they'll pay per unit of gas). This system serves multiple purposes: it prevents infinite loops and denial-of-service attacks by ensuring all computation is paid for, it creates a market for block space where users bid via gas prices, and it allows miners to set a minimum gas price they're willing to accept, protecting network resources.
Scalability remains a significant concern, as every node/" class="glossary-link" data-slug="full-node" title="full node">full node must process every transaction to verify the state. Current blockchain architectures struggle to match centralized systems' transaction throughput. Potential solutions include state sharding, where different nodes process different subsets of transactions, and a transition from proof-of-work to proof-of-stake consensus, which could enable more efficient block production. Light clients using Merkle proofs can verify transactions without processing all blocks, but someone must still process everything. These scalability challenges represent active areas of research and development critical to Ethereum's long-term viability.
Miscellanea And Concerns
L'implementation par Ethereum du protocole GHOST modifie inclut des regles specifiques pour l'inclusion et les recompenses des oncles. Les oncles doivent etre des enfants directs de l'ancetre du bloc actuel (entre 2 et 7 generations en arriere), doivent etre des en-tetes de bloc valides, doivent etre distincts des oncles precedents et ne doivent pas etre des ancetres directs du bloc actuel. Les blocs oncles recoivent 87,5% de la recompense de bloc standard, tandis que le bloc qui les inclut recoit un supplement de 3,125% par oncle inclus (jusqu'a deux oncles). Cette structure d'incitation encourage les mineurs a referencer les blocs perimes qu'ils observent, renforçant la securite du reseau tout en recompensant les mineurs qui ont temporairement eu de la malchance avec la propagation du reseau.
Le systeme de frais est base sur le concept de "gas", ou chaque operation de calcul a un cout fixe en gas. Par exemple, une operation de multiplication coute 5 gas, un hachage SHA256 coute 20 gas, et chaque transaction a un cout de base de 21 000 gas. Les utilisateurs specifient a la fois une limite de gas (le gas maximum qu'ils sont prets a consommer) et un prix du gas (combien d'ether ils paieront par unite de gas). Ce systeme sert plusieurs objectifs : il empeche les boucles infinies et les attaques par deni de service en garantissant que tout calcul est paye, il cree un marche pour l'espace de bloc ou les utilisateurs encherissent via les prix du gas, et il permet aux mineurs de fixer un prix minimum du gas qu'ils sont prets a accepter, protegeant les ressources du reseau.
L'evolutivite reste une preoccupation significative, car chaque noeud complet doit traiter chaque transaction pour verifier l'etat. Les architectures blockchain actuelles peinent a egaliser le debit de transactions des systemes centralises. Les solutions potentielles incluent le sharding d'etat, ou differents noeuds traitent differents sous-ensembles de transactions, et une transition de la preuve de travail vers un consensus par preuve d'enjeu, qui pourrait permettre une production de blocs plus efficace. Les clients legers utilisant des preuves de Merkle peuvent verifier les transactions sans traiter tous les blocs, mais quelqu'un doit quand meme tout traiter. Ces defis d'evolutivite representent des domaines actifs de recherche et de developpement critiques pour la viabilite a long terme d'Ethereum.
Conclusion
The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features like on-blockchain escrow, withdrawal limits, and financial contracts through a highly generalized programming language. However, the Ethereum protocol moves far beyond just currency. Protocols around decentralized file storage, decentralized computation, and decentralized prediction markets, among dozens of other concepts, have the potential to substantially increase the efficiency of the computational industry and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer.
Rather than providing a limited set of operations designed for specific use cases, Ethereum provides a Turing-complete programming language that enables developers to build any application they can design. Want to invent your own financial derivative? Create your own currency? Establish a government on the blockchain? These are all trivially implementable with Ethereum's scripting system. The platform's power lies not in predicting what applications will be built, but in providing the foundational infrastructure that makes building them easy.
The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides a platform with unique potential. Rather than being a closed-ended, single-purpose protocol intended for specific applications in data storage, gambling, or finance, Ethereum is open-ended by design, and we believe it is extremely well-suited to serving as a foundational layer for a large number of both financial and non-financial protocols in the years to come. The applications that will be built on Ethereum in the future may be ones we cannot even imagine today, and that open-ended possibility represents the true promise of the platform.
Conclusion
Le protocole Ethereum a ete initialement concu comme une version amelioree d'une cryptomonnaie, fournissant des fonctionnalites avancees comme l'entiercement on-blockchain, les limites de retrait et les contrats financiers a travers un langage de programmation hautement generalise. Cependant, le protocole Ethereum va bien au-dela de la simple monnaie. Les protocoles autour du stockage de fichiers decentralise, du calcul decentralise et des marches de prediction decentralises, parmi des dizaines d'autres concepts, ont le potentiel d'augmenter substantiellement l'efficacite de l'industrie informatique et de fournir un coup de pouce massif aux autres protocoles pair-a-pair en ajoutant pour la premiere fois une couche economique.
Plutot que de fournir un ensemble limite d'operations concues pour des cas d'utilisation specifiques, Ethereum fournit un langage de programmation Turing-complet qui permet aux developpeurs de construire toute application qu'ils peuvent concevoir. Vous voulez inventer votre propre derive financier ? Creer votre propre monnaie ? Etablir un gouvernement sur la blockchain ? Tout cela est trivialement implementable avec le systeme de script d'Ethereum. La puissance de la plateforme ne reside pas dans la prediction des applications qui seront construites, mais dans la fourniture de l'infrastructure fondamentale qui rend leur construction facile.
Le concept d'une fonction de transition d'etat arbitraire telle qu'implementee par le protocole Ethereum fournit une plateforme au potentiel unique. Plutot que d'etre un protocole ferme et a usage unique destine a des applications specifiques dans le stockage de donnees, les jeux d'argent ou la finance, Ethereum est ouvert par conception, et nous croyons qu'il est extremement bien adapte pour servir de couche fondamentale pour un grand nombre de protocoles financiers et non financiers dans les annees a venir. Les applications qui seront construites sur Ethereum a l'avenir pourraient etre celles que nous ne pouvons meme pas imaginer aujourd'hui, et cette possibilite ouverte represente la veritable promesse de la plateforme.
References and Further Reading
The Ethereum whitepaper builds upon extensive prior work in cryptocurrency and distributed systems research. The foundational Bitcoin protocol is described in Satoshi Nakamoto's original 2008 paper "Bitcoin: A Peer-to-Peer Electronic Cash System," which introduced the concept of blockchain-based digital currency. Early attempts to extend Bitcoin's functionality include Namecoin, a decentralized name registration system demonstrating blockchain applications beyond currency, though limited by Bitcoin's restricted scripting capabilities.
The colored coins whitepaper proposed a method for representing alternative assets on the Bitcoin blockchain by "coloring" specific bitcoins to represent other assets, while Mastercoin attempted to create a protocol layer on top of Bitcoin for more complex financial instruments. Both highlighted the limitations of building on Bitcoin and motivated the need for a more flexible platform. The concept of decentralized autonomous corporations, explored in Bitcoin Magazine, provided theoretical foundations for organizational governance through smart contracts.
Key technical components include simplified payment verification (SPV) for light clients, Merkle trees for efficient data verification, and Patricia tries for Ethereum's state representation. The GHOST (Greedy Heaviest Observed Subtree) protocol, described in a 2013 cryptography paper, addresses security issues arising from fast block times and forms the basis for Ethereum's consensus mechanism. These references represent the intellectual foundations upon which Ethereum was built, combining insights from cryptocurrency, distributed systems, cryptography, and game theory to create a general-purpose blockchain platform.
References and Further Reading
Le whitepaper d'Ethereum s'appuie sur de nombreux travaux anterieurs en recherche sur les cryptomonnaies et les systemes distribues. Le protocole Bitcoin fondateur est decrit dans l'article original de 2008 de Satoshi Nakamoto "Bitcoin: A Peer-to-Peer Electronic Cash System", qui a introduit le concept de monnaie numerique basee sur la blockchain. Les premieres tentatives d'extension des fonctionnalites de Bitcoin incluent Namecoin, un systeme d'enregistrement de noms decentralise demontrant des applications blockchain au-dela de la monnaie, bien que limite par les capacites de script restreintes de Bitcoin.
Le whitepaper des colored coins a propose une methode pour representer des actifs alternatifs sur la blockchain Bitcoin en "colorant" des bitcoins specifiques pour representer d'autres actifs, tandis que Mastercoin a tente de creer une couche de protocole par-dessus Bitcoin pour des instruments financiers plus complexes. Les deux ont mis en evidence les limitations de la construction sur Bitcoin et ont motive le besoin d'une plateforme plus flexible. Le concept de societes autonomes decentralisees, explore dans Bitcoin Magazine, a fourni les fondements theoriques de la gouvernance organisationnelle par le biais de smart contracts.
Les composants techniques cles incluent la verification simplifiee des paiements (SPV) pour les clients legers, les arbres de Merkle pour la verification efficace des donnees et les tries Patricia pour la representation de l'etat d'Ethereum. Le protocole GHOST (Greedy Heaviest Observed Subtree), decrit dans un article de cryptographie de 2013, traite les problemes de securite decoulant des temps de bloc rapides et constitue la base du mecanisme de consensus d'Ethereum. Ces references representent les fondements intellectuels sur lesquels Ethereum a ete construit, combinant des perspectives de la cryptomonnaie, des systemes distribues, de la cryptographie et de la theorie des jeux pour creer une plateforme blockchain generaliste.
Related Whitepapers
$USDT
Tether
Tether: Fiat currencies on the Bitcoin blockchain
30 shared concepts · 2016
$BCH
Bitcoin Cash
Bitcoin Cash: Peer-to-Peer Electronic Cash for the World
33 shared concepts · 2017
$DOGE
Dogecoin
Dogecoin: A Community-Driven Cryptocurrency
28 shared concepts · 2013
$USDC
USD Coin
USD Coin (USDC): A Stablecoin by Circle and Coinbase
20 shared concepts · 2018
$BTC
Bitcoin
Bitcoin: A Peer-to-Peer Electronic Cash System
20 shared concepts · 2008