Livre blanc Ethereum – version française


Préambule

Cet article est une libre traduction de la version originale anglaise du white book Ethereum disponible ici. A l’origine c’est un travail personnel destiné à améliorer ma compréhension d’Ethereum. Toutes erreurs ou approximations n’engagent que moi et je vous invite à vous référer à la version originale.

Une nouvelle génération de smart contract et de plateforme applicative décentralisée.

Le développement du Bitcoin par Satoshi Yakamoto a souvent été salué comme une révolution dans le domaine monétaire et des devises. Il s’agit en effet à la fois de la première monnaie digitale sans valeur intrinsèque sans support physique et sans émetteur, ni contrôleur centralisé.

Cependant un autre aspect, sans doute le plus important, de l’expérience Bitcoin est la technologie sous-jacente de chaine de blocs ou blockchain en tant qu’outil de mise en œuvre de consensus distribué. Et cette facette du Bitcoin suscite de plus en plus d’intérêts. Des alternatives couramment citées d’utilisation de la blockchain sont l’usage de celle-ci pour représenter des devises sur mesure et des instruments financiers (« colored coins »), la propriété de biens physiques (« smart property ») ou encore d’actifs non fongibles comme les noms de domaines (« name coins ») aussi bien que des applications plus complexes mettant en œuvre des actifs numériques contrôlés par de petits programmes implémentant des règles arbitraires (« smart contracts ») ou encore des Organisations Autonomes et Décentralisées (DAO pour Decentralized Autonomous Organisation). Ce qu’Ethereum ambitionne de fournir c’est une blockchain intégrant un langage Turing-complet à part entière qui peut être utilisé pour créer des «contrats» qui eux-mêmes peuvent être utilisés pour coder des fonctions de transition d’état arbitraires. Ce qui permet en définitive aux utilisateurs de créer l’un des systèmes décrits ci-dessus, ainsi que beaucoup d’autres que nous n’avons pas encore imaginés, en les programmant en seulement quelques lignes de code.

Introduction au Bitcoin et autres concepts existants

Histoire

Le concept de monnaie numérique décentralisée ainsi que d’autres applications comme l’enregistrement de titres de propriété, existent depuis quelques dizaines d’années. Les protocoles de « e-cash » anonymes des années 80 et 90 s’en remettaient à l’algorithme cryptographique de Chaum « Chaumian Blinding ». Le « Chaumian Blinding » a fourni alors à ces nouvelles monnaies un degré élevé d‘anonymat, mais leurs protocoles sous-jacents ont largement échoués à gagner du terrain en raison de leur dépendance à l’égard d’un intermédiaire centralisé.

En 1998 la « b-money » de Wei Dai fut la première proposition à introduire l’idée de produire de l’argent à partir de la résolution de problèmes informatiques ainsi que la notion de consensus décentralisé, mais la proposition était pauvre en détails sur la façon dont le consensus décentralisé pouvait effectivement être mis en œuvre.

En 2005, Hal Finney introduisit la notion de « preuves de travail réutilisables » (reusable proof of work), un système qui utilisait les idées de la b-money avec le système de preuve de travail Hashcash élaboré par Adams Back afin de créer la première cryptomonnaie. Là encore le système devait échouer car toujours basé sur serveur backend comme tiers digne de confiance.

En 2009, une monnaie décentralisée était pour la première fois mis en œuvre de manière pratique par Satoshi Nakamoto, en combinant à la fois les primitives cryptographiques éprouvées de la gestion de la propriété à clef publique avec un algorithme de consensus, pour conserver la trace de qui possède les unités monétaires, connu sous le nom de « preuve de travail ».
Le mécanisme derrière la preuve du travail a été une percée, car il a résolu simultanément deux problèmes. Tout d’abord, il a fourni un algorithme de consensus simple et relativement efficace, permettant aux nœuds du réseau de se mettre collectivement d’accord sur un ensemble de mises à jour de l’état du grand livre Bitcoin. Deuxièmement, il a fourni un mécanisme pour permettre l’entrée libre dans le processus de consensus, ce qui résout à la fois le problème politique de décider qui obtient d’influencer le consensus, tout en empêchant les attaques de type Sybil. Ce résultat est obtenu en substituant à un obstacle à la participation de type formel comme l’obligation d’être enregistré comme une entité unique sur une liste particulière, un obstacle économique : le poids d’un seul nœud dans le processus de vote par consensus est directement proportionnel à la puissance de calcul que le nœud apporte. Depuis lors, une approche alternative a été proposée appelé preuve de participation « proof of stake », qui calcule le poids d’un nœud comme étant proportionnel à ses avoirs en devises et non ses ressources de calcul. La discussion sur les mérites relatifs des deux approches va au-delà de la portée de ce document, mais il convient de noter que les deux approches peuvent être utilisées comme épine dorsale d’une crypto-monnaie.

Bitcoin en tant que Système de transition d’États

 

Schéma de transition d'état
D’un point de vue technique le grand livre d’une cryptomonnaie comme le Bitcoin peut être considéré comme un Système de Transition d’États dans lequel il y a un « état » qui correspond au statut de propriété de l’ensemble des bitcoins existants et une fonction de transition d’état qui prend un « état » et une transaction et génère un nouvel « état » qui en constitue le résultat. Dans un système bancaire classique, par exemple, l’état est un bilan comptable, une transaction est une demande de déplacer X$ de A à B, et la fonction de transition d’état réduit la valeur du compte A de X$ et augmente la valeur du compte B de X$. Si le compte de A a moins de X$ au départ, la fonction de transition d’état renvoie une erreur. Par conséquent, on peut formellement définir la fonction applicative :

APPLY(S,TX) -> S' or ERROR

Dans le système bancaire que nous venons de définir nous aurions :

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

Mais :

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

L’ « état » dans Bitcoin est la collection de toutes les pièces émises mais qui n’ont pas encore été dépensées (techniquement UTXO pour « Unspent Transaction Outputs »), chaque UTXO ayant une valeur nominale et un propriétaire (défini par une adresse de 20 octets qui est essentiellement une clé publique cryptographique[1]). Une transaction contient une ou plusieurs entrées, chaque entrée contenant une référence à un UTXO existant et une signature cryptographique produite par la clé privée associée à l’adresse du titulaire, et une ou plusieurs sorties, chaque sortie contenant une nouvelle UTXO qui s’ajoute à l’ « état ».
La fonction de transition d’état peut-être définie grossièrement de la manière suivante :

APPLY(S,TX) -> S’ avec les caractéristiques suivantes :

  1. Pour chaque entrée dans TX :
    • Si l’UTXO n’est pas référencé dans S retourner une erreur : Error
    • Si la signature fournie ne correspond pas au propriétaire de l’UTXO, retourner une erreur
  2. Si la somme des coupures de toutes les entrées UTXO est inférieure à la somme des coupures de toutes les sorties UTXO, retourner une erreur.
  3. Retourner S' avec toutes les UTXO d’entrée enlevées et toutes les sorties UTXO ajoutées.

La première instruction de l’étape 1 empêche l’insertion d’UTXO factices. La seconde instruction permet d’éviter d’opérer une transaction sans l’accord du propriétaire des pièces. La seconde instruction assure la conservation de la valeur du système. Pour utiliser cette fonction de paiement le protocole est le suivant : supposons qu’Alice veuille envoyer 11,7 BTC à Bob. Tout d’abord, Alice va chercher un montant disponible d’UTXO dans ceux qu’elle détient qui totalise au moins 11,7 BTC. Dans la réalité, Alice ne sera pas en mesure de réunir très exactement 11,7 BTC ; la plus petite somme qu’elle peut réunir sera 6 + 4 + 2 = 12 BTC. Alice va alors créer une transaction avec ces trois entrées et deux sorties. La première sortie est de 11,7 BTC avec l’adresse de Bob comme son nouveau propriétaire, et la seconde sortie sera de 0,3 BTC qui représente le reste ou « change ». Si Alice ne réclame son change en l’envoyant à une adresse dont elle est propriétaire le mineur peut le réclamer.

Minage

ethertransitionSi nous avions accès à un service centralisé de confiance, le système décrit serait trivial à mettre en œuvre ; il pourrait être codé exactement comme nous l’avons décrit, avec le support d’un disque dur sur un serveur centralisé pour garder une trace de l’état. Cependant, avec Bitcoin nous essayons de construire un système monétaire décentralisé, donc nous avons besoin de combiner le système de transition d’état à un système de consensus afin d’assurer que tout le monde est d’accord sur l’ordre des transactions. Le processus d’atteinte du consensus décentralisée de Bitcoin requiert que chaque nœud dans le réseau travaille en continu à la production de paquets de transactions appelées «blocs». Le réseau est destiné à créer un bloc d’environ toutes les dix minutes, chaque bloc contenant un horodatage, un identifiant unique ou nonce, une référence (c.-à-d un résultat de hachage) au bloc précédent et une liste de toutes les transactions qui ont eu lieu depuis ce bloc précédent. Au fil du temps, se crée la chaine de bloc, ou « blockchain » persistante qui se met à jour en permanence pour représenter l’état actuel de la comptabilité Bitcoin.

L’algorithme pour vérifier si un bloc est valide selon le paradigme décrit se présente comme ceci :

  1. Vérifier si le bloc précédent référencé par le bloc courant existe et qu’il est valide.
  2. Vérifier que l’horodatage(timestamp) du bloc courant est postérieur à celui du bloc précédent[2] et de moins de 2 heures dans l’avenir
  3. vérifier que la preuve du travail sur le bloc est valide.
  4. Prendre en entrée l’état s[0] comme l’état à la fin du bloc précédent.
  5. Supposons TX est le bloc de transaction de liste avec n transactions. Pour tous i dans 0...N-1, nous posons S[i] = APPLY(1 S[i],TX[i]) Si une des applications renvoie un message d’erreur, quittez et renvoyer false.
  6. Renvoyer Trues, et enregistrer S[n] comme l’État à la fin de ce bloc

Pour l’essentiel chaque transaction du bloc doit fournir un état de transition valable qui part de l’état canonique à partir duquel elle s’exécute pour aboutir au nouvel état. Notez que l’état n’est en aucune manière encodé dans le bloc ; c’est purement une abstraction qui va être mémorisées par le nœud de validation qui peut la recalculer (de manière sécurisée) pour chaque bloc à partir de l’état initial en le faisant de façon séquentielle à chaque transaction dans chaque bloc. En outre, notez que l’ordre dans lequel le mineur inclut les transactions dans le bloc compte ; s’il y a deux transactions A et B dans un bloc tel que B dépense un UTXO créé par A, alors le bloc sera valide si un A vient avant B mais pas dans le cas contraire.

La condition de validité présente dans la liste ci dessus est qui est unique est le la preuve de travail « proof of work ». Très précisément cette condition est que le hash double-SHA256 de chaque bloc traité comme un nombre de 256 bits doit être inférieur à un nombre cible ajusté dynamiquement qui à l’instant de la rédaction de cet article est approximativement 2187. Le but de cette condition est de rendre la création de bloc « dure » du point de vue temps de calcul et de prévenir ainsi les attaques Sybils qui viseraient à recréer toute la blockchain au profit de pirates. Comme SHA256 est conçut pour être une fonction pseudo aléatoire complétement imprévisible la seule manière de créer un bloc valide est tout simplement par essai/erreur en incrémentant de manière itérative le nonce jusqu’à il atteigne l’objectif.

Avec la valeur actuel de la cible à ~2187, le réseau doit réaliser en moyenne ~269 essais avant qu’un bloc valide ne soit trouvé ; en général la cible est réévaluée tous les 2016 blocs de telle sorte qu’en moyenne un bloc soit produit par un des nœuds du réseau toutes les 10 minutes. Afin de compenser les mineurs pour leur effort de calcul numérique, le mineur de chaque bloc est autorisé à introduire une transaction de 25 BTC en sa faveur créer à partir du néant. De plus si une transaction émet au total moins de valeur que les entrées, la différence va également au mineur comme commission de transaction (« transaction fee »).

Incidemment c’est également le seul et unique mécanisme par lequel les bitcoins sont créés. L’état initial ne comprenait aucun bitcoin du tout.

Pour mieux comprendre l’objectif du minage examinons ce qu’il se passe dans l’éventualité d’une attaque maligne. Étant donné que le Bitcoin est basé sur un système cryptographique réputé inviolable l’attaquant va cibler la seul partie du Bitcoin qui n’est pas protégée directement par la cryptographie à savoir l’ordre des transactions. La stratégie de l’attaquant est simple :

  1. Envoyer 100 BTC à un marchand en échange d’un produit (de préférence un bien numérique livrable immédiatement)
  2. Attendre pour la livraison du produit
  3. Produire une autre transaction envoyant les mêmes 100 BTC à lui-même
  4. tenter de convaincre le réseau que la transaction envoyée à lui même était la première.

Dès que l’étape (1) est réalisée, au bout de quelque minutes, un mineur va inclure la transaction dans un bloc, disons le bloc 270000. Une heure plus tard environ, cinq autres blocs se seront ajoutés à la chaine à la suite de ce premier bloc, chacun pointant indirectement vers la première transaction et la « confirmant ». A ce stade le marchand va considérer le paiement comme valable et livrer le produit, puisque nous partons du principe qu’il s’agit d’un bien digital livrable instantanément. Maintenant le pirate crée une nouvelle transactions s’envoyant 100 BTC à lui-même. Si le pirate envoie simplement cette transaction au réseau elle ne sera pas traitée. Les mineurs vont tenter de calculer APPLY(S,TX) et vont constater que TX consomme une UTXO qui ne fait plus partie de l’état. Aussi l’attaquant va plutôt créer un « fork » de la blockchain, en commençant à miner une autre version de la bloc 270000 pointant sur le même bloc 269999 comme parent mais avec la nouvelle transaction à la place de l’ancienne. Étant donné que le bloc de données est différent cela requière de recalculer la preuve de travail. De plus la nouvelle version du bloc 270000 produite par l’attaquant a un hash différent de telle sorte que les blocks 270001 à 270005 produit entre temps ne « pointent » pas dessus. La chaine original et la nouvelle sont donc complétement séparées. La règle en cas de branche(fork) multiple veut que ce soit la branche la plus longue qui soit retenue valide de telle sorte que les mineurs légitimes vont travailler sur la chaine 270005 alors que l’attaquant sera le seul à travailler sur la chaine 270000. Pour que l’attaquant puisse faire de sa chaine la plus longue il faudrait qu’il ait plus de pouvoir de calcul que tout le reste du réseau réunis pour refaire son retard (c’est l’attaque des 51%).

Arbre de Merkel

A gauche : Il suffit de recalculer une petit nombre de noeuds dans un arbre de Merkle pour donner une preuve de la validité de la branche. A droite : toute tentative pour changer quelque parties de l'arbre de Merkel abouti inévitablement à une incohérence en amont dans la chaine.

A gauche : Il suffit de recalculer une petit nombre de noeuds dans un arbre de Merkle pour donner une preuve de la validité de la branche.
A droite : toute tentative pour changer quelque parties de l’arbre de Merkel abouti inévitablement à une incohérence en amont dans la chaine.

Une des propriété fondamental de Bitcoin, qui permet la scalabilité du système, est que les blocs sont stockés dans une structure de données multi-niveau. Le ‘hash » d’un bloc est en réalité calculé seulement sur l’en-tête du bloc. Cela représente approximativement 200 octects de données constituées du timestamp, du nonce, du hash du bloc précédent et du hash de la racine de la structure appelée arbre de Merkel qui stocke toute les transactions dans le bloc. Un arbre de Merkle est un type d’arbre binaire composé : d’un jeu de nœuds avec un grand nombre de nœuds enfants à la base de l’arbre qui contiennent les données sous-jacentes, d’un jeu de nœuds intermédiaires où chaque nœud est le hash de ses deux enfants et au final un seul nœud racine lui même constitué du hash de ses deux nœuds enfants. Le but de l’arbre de Merkel est de permettre que les données d’un bloc soit délivrées au coup par coup : un nœud peut ne télécharger que le header d’un bloc depuis une première source, la portion de l’arbre pertinente pour lui d’une autre source et être tout de même assuré que toutes les données sont correctes. Cela fonctionne parce que les hash se propagent vers l’amont de l’arbre : si un utilisateurs malveillant tente une fausse transaction à la base de l’arbre ce changement provoquera un changement dans le nœud parent et dans le nœud parent du parent pour finalement changer le nœud racine de l’arbre et donc le hash du bloc. Ce qui au final d’après le protocole aboutira à l’enregistrement d’un bloc totalement différent (presque à coup sur avec une preuve de travail invalide)

Le protocole de l’arbre de Merkel est primordial pour la pérennité à long terme (du système). Un nœud complet dans le réseau Bitcoin qui traite intégralité de tous les blocs pèse environ 15 GB d’espace disque à la date d’Avril 2014, et il grandit d’un gigabyte par mois. C’est viable pour une ordinateur de bureau mais pas pour un téléphone et dans le futur seuls des professionnels ou des passionnés pourront participer au réseau. Un protocole connu sous le nom de « Simplified Payment Method » (SPV) permet à une autre classe de nœuds appelés « nœuds légers » (light nodes) d’exister. Ces nœuds télécharge les en-têtes de blocs vérifient la preuve de travail de l’en-tête et téléchargent alors seulement les branches associées avec les transactions pertinente pour lui. Ceci permet aux nœuds légers de déterminer avec un forte garantie de sécurité le statut de n’importe quelle transaction Bitcoin et leur balance courante en ne téléchargent qu’une toute petite partie de la blockchain.

Applications alternatives de la blockchain

L’idée d’utiliser les principes sous-jacents de la blockchain dans le cadre d’autres concepts a également une longue histoire. En 2005, Nick Szabo propose avec le concept de «titres de propriété sécurisés sous l’autorité des propriétaires » (ndt : « secure property titles with owner authority »), un document décrivant comment « de nouvelles avancées dans la technologie des bases de données répliquée » permettront de créer un système basé sur la blockchain pour stocker un registre des propriétaires de terrain, la création d’un cadre complexe pour gérer des concepts tels que le « homesteading »(ndt : droit de propriété acquis sur un terrain sans propriétaire de part son occupation et sa mise en valeur), usucapion (ndt : ou « prescription acquisitive » qui est le fait d’acquérir le droits de propriété d’un bien contre le propriétaire légitime du fait d’une occupation pérenne et paisible pendant un certain temps) et la taxe foncière Georgiste (ndt : le Georgisme est une théorie économique selon laquelle la valeur économique des produits dérivés de la terre ou plus largement des ressources naturelles appartient à tout les membres de la communauté mais que chacun est propriétaire de la valeur économique qu’il produit par lui-même). Cependant, il n’y avait malheureusement pas de système de base de données répliquée efficace disponible à l’époque, et ainsi le protocole n’a jamais été mis en œuvre dans la pratique. Après 2009, cependant, une fois que le consensus décentralisé de Bitcoin a été développé un certain nombre d’autres applications a rapidement commencé à émerger.

  • Namecoin – créé en 2010, la meilleure manière de définir le Namecoin est comme base de registre de nommage décentralisée. Dans des protocoles décentralisés comme Tor, Bitcoin et BitMessage il y a nécessité d’identifier les compte de manière à ce qu’ils puissent interagir entre eux, mais dans toutes ces solutions le seul identifiant valable est un hash pseudo aléatoire comme 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Idéalement quelqu’un pourrait avoir un compte avec un nom comme « George ». Mais le problème est que si quelqu’un peut créer un compte nommé « George » une autre personne peut utiliser le même processus pour enregistrer ce même nom de « George » et usurper ainsi le premier compte. La seule solution est d’avoir un registre basé sur le paradigme « first-to-file » (ndt : premier enregistré) ou le premier à s’inscrire entraine l’échec des inscriptions ultérieures, en somme un problème parfaitement adapté au protocole de consensus Bitcoin. Namecoin est la plus ancienne et la plus réussie des implémentations d’un système de registre de nom utilisant cette idée.
  • Colored coins – l’objectif de colored coins est de servir de protocol pour permettre à chacun de créer leur propre cryptomonnaie ou dans le cas trivial mais important d’une monnaie avec une seule unité de créer un jeton digital basé sur la blockchain Bitcoin. Dans le protocole colored coins quelqu’un « émet » une nouvelle monnaie assignant publiquement une « couleur » à un UXTO Bitcoin spécifique et le protocole assigne récursivement la couleur de l’UTXO d’entrée aux UTXO que la transaction dépense (un règle spéciale s’applique en cas d’entrée de plusieurs couleurs). Ceci permet aux utilisateurs de gérer des portefeuille contenant seulement des UTXO d’une couleur spécifique et de les utiliser comme des bitcoins classiques en les traçants à travers la blockchain pour déterminer la couleur de tout UTXO qu’ils reçoivent.
  • Metacoins – L’idée à la base du metacoin est d’avoir un protocole qui vit au dessus du protocole Bitcoin en utilisant les transactions Bitcoin pour stocker les transactions metacoin mais avec un état de transition différent de la fonction APPLY'. Comme le protocole metacoin ne peut empêcher les transactions metacoin invalides d’apparaitre ans le blockchain Bitcoin une règle a été aoutée qui si la fonction APPLY'(S,TX) retourne une erreur le protocole renvoie la fonction APPLY'(S,TX) = S. Ceci procure une mécanisme simple pour créer une cryptomonnaie arbitraire avec potentiellement des fonctionnalités avancées qui ne peuvent pas être implémentées dans le protocole Bitcoin lui-même et ce avec un coût de développement faible puisque la complexité du minage et du réseau est déjà supportée par le protocole Bitcoin. Les metacoins ont été utilisés pour implémenter certains types de contrats financiers, de registres de nom et d’échanges décentralisés.

D’une manière générale on a ainsi deux approches pour créer un protocole consensuel : créer un réseau indépendant ou créer un protocole au dessus de Bitcoin. La première approche bien qu’ayant connu un certain succès dans le cas d’application comme le Namecoin est difficile à implémenter ; chaque implémentation individuelle nécessite de générer une blockchain indépendante aussi bien que de construire et tester tous les états de transition et le code du réseau. En outre nous prédisons que l’ensemble des applications de la technologie de consensus décentralisée suivra une loi de répartition de la puissance où la grande majorité des applications serait trop faible pour justifier leur propre blockchain, et nous constatons également qu’il existe de nombreuses classes d’applications décentralisées, en particulier les DAO, qui ont besoin d’interagir les unes avec les autres.

L’approche basée sur le Bitcoin d’autre part a le défaut qu’elle n’hérite pas des caractéristiques de vérification des paiements simplifiés (SPV) de Bitcoin. SPV fonctionne pour le Bitcoin parce le protocole peut utiliser la profondeur de la blockchain comme proxy pour les validations ; à un certain point si les ancêtres d’une transaction remontent suffisamment loin on peut affirmer de manière sûre qu’ils font légitimement partie de l’état. Les méta-protocoles basés sur la blockchain, d’autre part, ne peuvent pas forcer la blockchain à ne pas inclure les transactions qui ne sont pas valables dans le cadre de leurs propres protocoles. Par conséquent un méta-protocole SPV complétement sécurisé devrait scanner de manière rétroactive tous les branches depuis le commencement de la blockchain Bitcoin pour déterminer si oui ou non certaines transactions sont valides. Actuellement, toutes les implémentations « light » de méta-protocoles basées sur Bitcoin reposent sur un serveur de confiance pour fournir les données, sans doute un résultat très sous-optimal quand l’un des principaux objectifs d’une crypto-monnaie est d’éliminer le besoin de tiers de confiance.

Programmation

Même sans aucune extension, le protocole Bitcoin ne facilite vraiment pas la création du concept de « smart contracts ». Les UTXO dans Bitcoin peuvent être détenus au travers d’une clef publique mais également par un script plus compliqué écrit dans une langage de programmation basé sur une pile simple. Dans ce paradigme, une transaction dépensant une UTXO doit fournir les données satisfaisants au script. En effet même le mécanisme de base de clef public propriétaire est implémenté via un script : le script utilise une signature à courbe elliptique comme entrée pour vérifier l’adresse qui possède l’UTXO dans la transaction et retourne 1 si la vérification est un succès et 0 dans le cas contraire. D’autres scripts plus compliqués existent pour d’autres usages. Par exemple on peut construire un script qui requiert deux signatures d’un pool de trois pour valider (« multisig ») la transaction, une configuration utile pour un compte d’entreprise, sécuriser des comptes épargnes, ou encore dans des transactions marchandes impliquant un tiers intervenant.

Les scripts peuvent également être utilisés pour payer les primes à la résolution de problèmes de calcul, et on peut même construire un script qui dit quelque chose comme « ce Bitcoin UTXO est le vôtre si vous pouvez fournir une preuve SPV que vous avez envoyé une transaction Dogecoin avec cet identifiant pour moi«  , ce qui permet par exemple les échanges inter-crypto-monnaies.

Cependant, le langage de script telle que transposée dans Bitcoin a plusieurs limites importantes :

  • Il n’est pas Turing-complet – ce qui veut dire que bien qu’il implémente la plupart des fonctionnalités d’un langage de script il ne permet pas tout. La principale catégorie manquante sont les boucles. Ceci est voulu pour éviter les boucles infinies durant la vérifications des transactions. En théorie c’est un obstacle surmontable par les programmeurs car une boucle peut toujours être simulée par la répétition du code exécuté à chaque tour avec une condition (if statement, ndt), néanmoins le script devient alors très verbeux et consommateur d’espace. Par exemple implémenter un algorithme alternatif la la courbe elliptique requerrait la répétition de 256 multiplications dans le code même.
  • Cécité de valeurs – Il n’y a aucune possibilité pour un script UTXO de fournir un contrôle du montant qui peut être retirer avec une granularité fine. Par exemple un cas d’utilisation puissant d’un contrat de prédiction pourrait un contrat à terme ou A et B mettent une valeur de 1000$ en BTC et après 30 jours le script renvoie un montant de 1000$ en BTC à A et le reste à B. Cela requiert de pouvoir prédire la valeur de 1 BTC en USD mais même comme cela c’est une amélioration énorme en terme de confiance et pré-requis techniques par rapport aux solutions complétement centralisées disponibles actuellement. Cependant comme les UTXO sont tout ou rien le seul moyen d’implémenter ce contrat est d’utiliser le très inefficace contournement (ndt : hack) qui consiste une collection d’UTXO nommées différemment (Ex. 1 UTXO parmi 2k pour chaque k jusqu’à 30) et avoir O choix sur quel UXTO envoyer à A et lequel envoyer à B.
  • Absence d’état – un UTXO peut être soit dépensé soit non dépensé ; il n’y a pas de place pour les contrats multi-étapes ou des scripts qui référencent d’autres états interne au-delà de ces deux là. Cela rend difficile la fabrication de contrats d’options multi-étapes, des offres d’échanges décentralisées ou des protocoles d’engagement cryptographiques en deux étapes (nécessaire pour les primes de résolution de calcul sécurisées). Cela signifie également qu’un UTXO ne peut être utilisée que pour construire des contrats simples et ponctuels et non des contrats plus complexes à états (« stateful » ndt) tels que les organisations décentralisées le nécessitent, et que cela rend les méta-protocoles difficiles à mettre en œuvre. L’état binaire combiné avec la valeur-cécité signifie également qu’une autre application importante : les limites de retrait, est impossible.
  • Cécité de Blockchain – Les UTXO sont aveugles sur certaines données de la blockchain comme les nonces et les hash des bloc précédents. Cela limite sévèrement les applications de jeux et dans ne nombreuses autres catégories en privant le langage de programmation d’une source valable de valeurs aléatoires.

Nous voyons ainsi trois approches pour construire des applications avancées sur une base de crypto-monnaie : la construction d’une nouvelle blockchain, l’utilisation des scripts du Bitcoin, et la construction d’un méta-protocole sur base Bitcoin. Construire une nouvelle blockchain permet une liberté illimitée dans la construction d’un ensemble de fonctionnalités, mais au coût du temps de développement, de l’effort de lancement et de la sécurité. L’utilisation de scripts est facile à mettre en œuvre et normalisé, mais est très limitée en terme de capacités, quant aux méta-protocoles, bien que confortable, ils souffrent de défauts en terme de scalabilité. Avec Ethereum, nous avons l’intention de construire un cadre alternatif qui offre des gains encore plus importants en terme de facilité de développement, des propriétés avancées pour les clients légers, tout en permettant en même temps aux applications de partager un environnement économique et la sécurité blockchain.

Ethereum

Le but d’Ethereum est de créer un protocole alternatif pour construire des applications décentralisées, fournissant un ensemble différent de compromis que nous pensons être très utile pour une large classe d’applications décentralisées, avec un accent particulier sur les situations où les temps de développements doivent être courts, la sécurité assurée même pour les petites applications rarement utilisées, et la capacité des différentes applications d’interagir de manière très efficace importante. Ethereum fait cela en construisant l’essentiel la couche fondamentale abstraite ultime : une blockchain avec un langage de programmation intégré Turing-complet, permettant à quiconque de rédiger des contrats intelligents et des applications décentralisées où l’on peut créer ses propres règles arbitraires pour la propriété, les formats de transaction et les fonctions de transition d’état. Une version dépouillée de Namecoin peut être écrite en deux lignes de code, et d’autres protocoles comme les devises et les systèmes de réputation peut être construits en moins de vingt. Des contrats intelligents, des «boîtes» cryptographiques qui contiennent la valeur et ne sont déverrouillées que si certaines conditions sont remplies, peuvent également être construit au-dessus de la plate-forme, avec beaucoup plus de puissance que celle offerte par le langage de script Bitcoin en raison des capacités supplémentaires que sont l’aspect Turing-complet, la connaissance de la valeur, la connaissance de la blockchain et la connaissance de l’état.

Comptes Ethereum

Dans Ethereum, l’état est composé d’objets appelés «comptes», chaque compte ayant une adresse de 20 octets, les transitions d’état sont les transferts directs de valeurs et d’informations entre les comptes. Un compte Ethereum contient quatre champs :

  • Le nonce, un compteur utilisé pour assurer que chaque transaction ne peut être traitée qu’une fois,
  • la balance actuel en ether du compte,
  • le code source du contrat du compte, s’il y en a un,
  • le stockage du compte (vide par défaut).

L' »Ether » est le principal crypto-carburant interne d’Ethereum, il est utilisé pour payer les frais de transaction. En général, il existe deux types de comptes : les comptes externes (ndt : dont le propriétaire est externe au système), contrôlés par des clés privées et des comptes de contrats, contrôlés par leur code de contrat. Un compte appartenant à l’extérieur n’a pas de code, et on peut envoyer des messages à partir d’un compte externe en créant et en signant une transaction; dans un compte de contrat, chaque fois que le compte du contrat reçoit un message, son code s’active, ce qui lui permet de lire et écrire dans sa mémoire interne et d’envoyer d’autres messages ou créer des contrats en retour.

Notez que les «contrats» dans Ethereum ne doivent pas être considérés comme quelque chose qui devrait être «rempli» ou «respecté»; ils sont plutôt comme des «agents autonomes» qui vivent à l’intérieur de l’environnement d’exécution Ethereum, exécutant toujours une partie spécifique du code lorsqu’ils sont activés par un message ou une transaction, ils ont un contrôle direct sur leur propre équilibre d’éther et de leur propre clé/valeur de stockage pour garder une trace des variables persistantes.

Messages et transactions

Le terme «transaction» est utilisé dans Ethereum en référence à un paquet de donnée signé qui stocke un message à envoyer à partir d’un compte externe. Les transactions contiennent :

  • Le destinataire du message,
  • Une signature identifiant l’expéditeur,
  • La quantité d’éther pour transférer de l’expéditeur au destinataire,
  • Un champ de données en option,
  • Une valeur de STARTGAS, ce qui représente le nombre maximum d’étapes de calcul de l’exécution que la transaction est autorisée à prendre,
  • Une valeur de GASPRICE, représentant les frais de l’expéditeur paie par étape de calcul.

Les trois premiers sont des champs standards attendus dans toutes les crypto-monnaie. Le champ de données n’a pas de fonction par défaut, mais la machine virtuelle a un opcode avec lequel un contrat peut accéder aux données ; Un exemple de cas d’utilisation, est un contrat qui fonctionnerait comme un service d’enregistrement de domaine sur blockchain, il voudra interpréter les données passées à lui comme contenant deux «champs», le premier champ étant un domaine à enregistrer et le second champ étant l’adresse IP à associer. Le contrat lit ces valeurs à partir des données du message et les place dans le stockage de manière appropriée .
Les champs STARTGAS et GASPRICE sont cruciaux pour l’anti-déni de service (ndt : Denial Of Service) du modèle Ethereum. Afin d’éviter les boucles infinies accidentelles ou hostiles ou d’autres gaspillages de temps de calculs dans le code, chaque transaction doit fixer une limite au nombre d’étapes de calcul pour l’exécution du code qu’elle peut utiliser. L’unité fondamentale de calcul est le «gaz» ; généralement, une étape de calcul coûte 1 gaz, mais certaines opérations coûtent des quantités plus élevées de gaz car ils sont plus coûteux en calcul, ou d’augmenter la quantité de données qui doivent être stockées dans le cadre de l’Etat. Il y a aussi une taxe de 5 gaz pour chaque octet dans les données de transaction. Le but du système de redevance est d’exiger d’un attaquant de payer proportionnellement pour chaque ressource qu’il consomme, y compris le calcul, la bande passante et le stockage ; par conséquent, toute transaction qui amène le réseau à consommer une plus grande quantité de l’une de ces ressources doit fournir un montant de gaz à peu près proportionnel à l’augmentation.

Messages

Les contrats ont la possibilité d’envoyer des « messages » à d’autres contrats. Les messages sont des objets virtuels qui ne sont jamais sérialisés et existent uniquement dans l’environnement d’exécution Ethereum. Un message contient :

  • L’expéditeur du message (implicite),
  • Le destinataire du message,
  • La quantité d’éther transférée avec le message,
  • Un champ de données en option,
  • Une valeur STARTGAS.

Pour l’essentiel un message est comme une transaction, sauf qu’il est produit par un contrat et non par un compte externe. Un message est produit quand un contrat en cours d’exécution de code exécute l’opcode CALL, qui produit et exécute un message. Comme une transaction, un message conduit au compte du destinataire en cours d’exécution de son code. Ainsi, les contrats peuvent avoir des relations avec d’autres contrats exactement de la même façon que les comptes externes le peuvent.

Notez que l’allocation de gaz affecté par une transaction ou un contrat s’applique à la totalité du gaz consommé par cette transaction et toutes les sous-exécutions. Par exemple, si un acteur externe A envoie une transaction à B avec 1000 gaz et B consomme 600 gaz avant d’envoyer un message à C, et que l’exécution interne de C consomme 300 gaz avant de revenir, alors B peut dépenser encore 100 gaz avant de tomber en panne d’essence.

Fonction de transition d’état d’Ethereum

etat de transition ethereum

états de transition ethereum

La fonction Ethereum de transition d’état, APPLIQUE (S, TX) -> S'peut être défini comme suit :

  1. Vérifier si la transaction est bien formée (ex. Elle a le bon nombre de valeurs renseignées), si la signature est valide, et si le nonce correspond au nonce du compte de l’expéditeur. Sinon, retourner une erreur.
  2. Calculer les frais de transaction comme STARTGAS * GASPRICE, et déterminer l’adresse d’expedition d’après la signature. Soustraire les frais du solde du compte de l’expéditeur et incrémenter le nonce de l’expéditeur. S’il n’y a pas de solde disponible pour exécuter la transaction, retourner une erreur.
  3. Initialiser GAS = STARTGAS, et enlever une certaine quantité de gaz par octet à payer pour les octets dans la transaction.
  4. Transférer la valeur de la transaction du compte de l’expéditeur au compte de réception. S’il n’existe pas encore compte de réception le créer. Si le compte de réception est un contrat, exécutez le code du contrat, soit jusqu’à la fin ou jusqu’à ce que l’exécution soit à court de gaz.
  5. Si le transfert de la valeur a échoué parce que l’expéditeur n’a pas assez d’argent, ou que l’exécution du code est à court de gaz, annuler tous les changements d’état, à l’exception du paiement des frais, et ajouter les frais sur le compte du mineur.
  6. Sinon, rembourser les frais pour tous les gaz restant à l’expéditeur, et envoyer les frais payés pour le gaz consommé au mineur.

Par exemple, supposons que le code du contrat soit :

if !self.storage[calldataload(0)]:
self.storage[calldataload(0)] = calldataload(32)

Notez que, en réalité, le code de contrat est écrit dans le code EVM (ndt : Ethereum Virtual Machine) bas niveau ; cet exemple est écrit en Serpent, l’un de nos langages de haut niveau, pour plus de clarté, et peut être compilé en code EVM. Supposons que le stockage du contrat commence à vide, et qu’une transaction est envoyée avec 10 ethers, 2000 valeur de gaz, au prix de 0,001 ether par gaz, et 64 octets de données, avec des octets 0-31 représentant le nombre 2 et d’octets 32-63 représentant la chaîne CHARLIE. Le processus pour la fonction de transition d’état dans ce cas est le suivant :

  1. Vérifier que la transaction est valide et bien formée.
  2. Vérifier que l’expéditeur de la transaction a au moins 2000 * 0,001 = 2 ether. Si c’est le cas, soustraire 2 éther à partir du compte de l’expéditeur.
  3. Initialiser le gaz = 2000; en supposant que la transaction est de 170 octets et le coût de l’octet est de 5, soustraire 850 gaz de sorte qu’il reste 1150 gaz.
  4. Soustraire 10 ether de plus à partir du compte de l’expéditeur, et l’ajouter au compte du contrat.
  5. Exécuter le code. Dans ce cas, c’est simple: il vérifie si le stockage du contrat à l’index2 est utilisé, remarque qu’il ne l’est pas, et il définit la valeur CHARLIE à l’index2 du stockage. Supposons que cela prend 187 gaz, de sorte que la quantité restante de gaz est 1150-187 = 963
  6. Ajouter 963 * 0,001 = 0,963 ether en retour sur le compte de l’expéditeur, et retourner l’état résultant du processus.

S’il n’y avait pas de contrat (ndt : donc de code à exécuter) pour recevoir la transaction, les frais de transaction totaux seraient tout simplement égaux au GASPRICE prévue multiplié par la longueur de la transaction en octets, et les données envoyées aux côtés de la transaction ne seraient pas pertinentes.

Notez que les messages fonctionnent de manière équivalente aux transactions en termes de réversion : si un message d’exécution est à court de gaz, alors l’exécution de ce message, et toutes les autres exécutions déclenchées par cette exécution, sont annulées, mais les exécutions parentes n’ont pas besoin d’être annulées. Cela signifie qu’il est «sûr» pour un contrat d’appeler un autre contrat, si A appelle B avec G gaz, alors l’exécution de A est assurée de perdre au plus le gaz G. Enfin, notez qu’il y a un opcode, CREATE, qui crée un contrat; sa mécanique d’exécution est globalement similaire à un CALL, à l’exception du fait que la sortie de l’exécution détermine le code d’un contrat nouvellement créé ad hoc.

Exécution du code

Le code dans les contrats Ethereum est écrit dans un langage bas niveau(code natif de la pile d’exécution), appelée « code machine virtuelle Ethereum » ou « code EVM ». Le code se compose d’une série d’octets, chaque octet représente une opération. D’une manière générale, l’exécution du code est une boucle infinie qui consiste à effectuer de façon répétée l’opération au compteur de programme en cours (qui commence à zéro), puis incrémenter le compteur de programme par un, jusqu’à la fin du code est atteinte ou si une erreur ou une instruction STOP ou RETURN est détectée. Les opérations ont accès à trois types d’espace pour stocker des données :

  • La pile, Last In First Out container auquel les valeurs peut être affectées et extraites
  • La Mémoire, un tableau d’octets extensible à l’infini
  • le stockage à long terme du contrat, un stockage clé / valeur. Au contraire de la pile et de la mémoire, qui sont réinitialisés après la fin du calcul, le stockage persiste à long terme.

Le code peut également accéder aux valeurs du message : expéditeur et les données du message entrant, ainsi qu’aux données d’en-tête de bloc, et le code peut également renvoyer un tableau d’octets de données en tant que sortie.

Le modèle d’exécution formelle du Code EVM est étonnamment simple. Alors que la machine virtuelle Ethereum est en cours d’exécution, son état de calcul complet peut être défini par le tuple (block_state, transaction, message, code, mémoire, pile, pc, gaz), où block_state est l’état global contenant tous les comptes et qui inclut les soldes et le stockage. Au début de chaque tour d’exécution, l’instruction en cours est trouvée en prenant l’octet pc du code (ou 0 si pc >= len (code)), et chaque instruction a sa propre définition sur la manière dont elle affecte le tuple. Par exemple, ADD extrait deux éléments de la pile et pousse leur somme, réduit le gaz par 1 et incrémente pc par 1, et SSTORE pousse les deux premiers articles de la pile et insère le deuxième élément dans le stockage du contrat à l’index spécifié par le premier élément. Bien qu’il existe de nombreuses façons d’optimiser l’exécution de la machine virtuelle Ethereum via la compilation juste-à-temps, une implémentation de base de l’Ethereum peut être fait en quelques centaines de lignes de code.

Blockchain et Minage

Diagramme d'application

Diagramme d’application

La blockchain Ethereum est à bien des égards similaire à la blockchain Bitcoin, même si elle présente quelques différences. La principale différence entre Ethereum et Bitcoin à l’égard de l’architecture blockchain est que, contrairement à Bitcoin, les blocs Ethereum contiennent une copie de la liste à la fois des transactions et de l’état le plus récent. Mis à part cela, la blockchain Ethereum contient deux autres valeurs, le numéro de bloc et de la difficulté, qui sont également stockées dans le bloc. L’algorithme de validation du bloc de base dans Ethereum est la suivante :

  1. Vérifier si le bloc précédent référencé existe et qu’il est valide.
  2. Vérifier que l’horodatage du bloc courant est ultérieur à celui du bloc précédent référencé et de moins de 15 minutes dans le futur
  3. Vérifier que le numéro de bloc, la difficulté, la transaction racine, la racine de l’oncle(ndt : uncle root) et la limite de gaz (divers concepts bas niveaux spécifiques à Ethereum) sont valides.
  4. Vérifier que la preuve du travail sur le bloc est valide.
  5. Soit S[0] l’état à la fin du bloc précédent.
  6. Soit TX la liste des transactions du bloc, avec n transactions. Pour tout i dans 0 ... n-1, poserS[i + 1] = APPLY(S [i], TX [i]). Si une des exécution de la fonction renvoie une erreur, ou si le gaz total consommé dans le bloc dépasse le GASLIMIT, alors retourner une erreur.
  7. Soit S_FINAL est égal à S[n], mais en ajoutant au bloc la prime versée au mineur.
  8. Vérifier que la racine de l’arbre de Merkel de l’état finalS_FINAL est égale à la racine de l’état final fournie dans l’en-tête de bloc. Dans ce cas, le bloc est valide; sinon, il n’est pas valide.

L’approche peut sembler très inefficace à première vue, car il faut stocker l’état entier dans chaque bloc, mais en réalité, l’efficacité est comparable à celle de Bitcoin. En effet l’état est stocké dans la structure de l’arbre, et après chaque calcul de bloc seulement une petite partie de cette arborescence a besoin d’être modifiée. Ainsi, entre deux blocs adjacents la plus grande part de l’arborescence est identique, et par conséquent les données peuvent être stockées une fois et référencé deux fois en utilisant des pointeurs (ex. hash des sous-arborescences). Un type particulier d’arbre connu comme un « arbre Patricia » (ndt : arbre radix) est utilisé pour arriver à ce résultat, ainsi qu’une modification de la notion d’arbre de Merkle qui permet d’insérer et de supprimer des noeuds, en plus de les modifier, de manière efficace. En outre, parce que toutes les informations d’état font partie du dernier bloc, il n’y a pas besoin de stocker toute l’histoire de blockchain – une stratégie qui, si elle été appliquée à Bitcoin, pourrait économiser de l’espace disque avec un ratio de x5 à x20.

Une question souvent posée est « où » le code du contrat est exécuté matériellement parlant. La réponse est simple: le processus d’exécution du code d’un contrat fait partie de la définition de la fonction de transition d’état, qui elle-même fait partie de l’algorithme de validation de bloc, donc si une transaction est ajouté dans le bloc B l’exécution de code engendrée par cette opération sera exécutée par tous les nœuds, maintenant et à l’avenir, à chaque téléchargement et validation du bloc B.

Applications

En général, il existe trois types d’applications basée sur Ethereum. La première catégorie est celle des applications financières, fournissant aux utilisateurs des moyens plus variés et puissants de gestion et de contractualisation avec leur argent. Cela inclut les sous-monnaies, les instruments financiers dérivés, des contrats de couverture à terme, les portefeuilles d’épargne, les testaments, et, finalement, même certaines catégories de contrats de travail à grande échelle. La deuxième catégorie est celle des applications semi-financières, où l’argent est impliquée, mais où il y a aussi un côté non monétaire très important dans l’exécution du contrat ; l’exemple parfait est celui des primes automatiques pour la résolution de problèmes de calcul. Enfin, il existe des applications telles que le vote en ligne et la gouvernance décentralisée qui ne sont pas du tout financières.

Système de token

Les systèmes de token (ndt : jetons) implémentés sur la blockchain ont de nombreuses applications allant de la sous-monnaies représentant des actifs tels que l’USD, l’or ou les actions des entreprises, des token individuels représentant une « smart property » (titre ou acte de propriété distribué), sécuriser des coupons infalsifiables, et même des points symboliques sans attaches avec une valeur conventionnelle, pour des actions « d’incentive ». Les systèmes de token sont étonnamment faciles à mettre en œuvre dans Ethereum. Le point essentiel à comprendre est que toute monnaie, ou système de jetons, est fondamentalement constitué d’une base de données et d’une seule opération: soustraire X unités de A et donner les X unités à B, à condition que (1) A avait au moins X unités avant la transaction et (2) que la transaction est approuvée par A. Tout ce qu’il faut pour mettre en œuvre un système de jetons est de coder cette logique dans un contrat.

Le code de base pour la mise en œuvre d’un système de token en Serpent se présente comme suit:

def send(to, value):
if self.storage[msg.sender] >= value:
self.storage[msg.sender] = self.storage[msg.sender] - value
self.storage[to] = self.storage[to] + value

Ce code est pratiquement une application littérale de la fonction «système bancaire» de transition d’état décrite plus haut dans ce document. Quelques lignes de code supplémentaires doivent être ajoutées pour l’étape initiale de la distribution des unités monétaires et quelques autres pour gérer les cas aux limites, et idéalement enfin une fonction seraient ajoutée pour permettre à d’autres contrats de requêter la balance courante d’une adresse. Mais c’est tout ce qu’il y a à faire. Théoriquement, les systèmes de token basés sur Ethereum peuvent potentiellement inclure une autre caractéristique importante qui manque aux méta-monnaies basées sur la blockchain Bitcoin : la capacité de payer des frais de transaction directement dans cette monnaie. Cela peut-être mis en oeuvre en intégrant dans le contrat un compte de réserve en ether pour rembourser en ether les frais à l’émetteur, compte maintenu à l’équilibre en revendant aux enchère les commissions prises par le contrat dans la méta-monnaie en un flux constant. Les utilisateurs auraient donc besoin d’«activer» leurs comptes avec de l’éther, mais une fois que l’éther est là, il serait réutilisable parce que le contrat serait remboursé chaque transaction.

Produits financiers dérivés et monnaie à valeur stable

Les produit financiers dérivés sont l’application la plus courantes des « smart contracts » et une des plus simple à implémenter. le plus grand défis dans la programmation des contrats financiers est que la plupart d’entre eux nécessitent une référence à une cote de prix externe. Par exemple une application souhaitable est un contrat qui couvre contre la volatilité de l’ether (ou de tout autre cryptomonnaie) par rapport au dollar américain. Mais faire cela requiert que le contrat connaisse la valeur ETH/USD. La façon la plus simple de faire cela et au travers d’un contrat de fourniture de données maintenue par un tiers spécifique (par exemple le NASDAQ) structuré de manière à mettre à jour le contrat et doté dune interface qui permet aux autres contrats de lui envoyé un message pour obtenir en retour une réponse avec le prix demandé.
En prenant en compte cet ingrédient critique le contrat de couverture ressemblerait à ceci :

  1. Attendre que le partie A entre 1000 ether.
  2. Attendre que le partie B entre 1000 ether.
  3. Enregistré en stock la valeur en dollars US de 1000 ether calculée en interrogeant le contrat de fourniture de données avec la valeur x$.
  4. Après 30 jours, autoriser A ou B à « réactiver » le contrat pour envoyer la valeur de x$ en ether (calculé en interrogeant de nouveau le contrat de fourniture de données pour obtenir le nouveau prix) à A et le reste à B.

Un tel contrat aurait un potentiel significatif en crypto-commerce. Un des principaux problème évoqué à propos des crypto-monnaies et le fait qu’elles soient volatiles ; bien que de nombreux utilisateurs et marchands puissent souhaiter bénéficier de la sécurité et de la praticité des actifs cryptographiques en revanche ils ne veulent pas assumer le risque de perdre 23% de la valeur de leur fond en un seul jour. A ce jour la solution la plus communément proposée est un actif « maison » créé par l’émetteur. L’idée est qu’un émetteur crée une sous-monnaie dans la quelle il a le droit de créer ou de révoquer les unités de valeurs et de fournir une unité de cette valeur à quiconque leur donne en retour (offline) une unité de l’actif sous-jacent spécifique (ex : or ou dollars). L’émetteur s’engage alors à fournir une unité de l’actif sous-jacent à quiconque lui renvoie une unité de l’actif cryptographique. Ce mécanisme permet à beaucoup d’actifs non-cryptographique d’être upgradé en un actif cryptographique si tant est que l’émetteur soit digne de confiance.
Dans la pratique néanmoins, les émetteurs ne sont pas toujours dignes de confiance et dans certains cas l’infrastructure bancaire est trop faible ou trop hostile pour qu’un tel service existe. Les dérivées financières fournisse une alternative. En l’espèce à la place d’un seul émetteur fournisseur les fond pour soutenir l’actif un marché décentralisé de spéculateurs, pariant sur le fait que le prix de la d’actif cryptographique de référence (ex : ETH) va grimper joue ce rôle. A la différence des émetteurs les spéculateurs n’ont pas la possibilité de faire défaut sur leur part d u marché car le contrat de couverture détient leurs fond en dépôt. Notez que cette approche n’est pas complétement décentralisée car une source de confiance est toujours nécessaire pour fournir la cote du prix, bien que l’on puisse toujours arguer que cela reste une amélioration massive en terme de réduction des pré-requis d’infrastructure (à la différence d’un émetteur d’actif, émettre un prix ne nécessite aucune licence et peut être catégorisé comme un « discours libre ») et une réduction du potentiel de fraude.

Identité et système de réputation

La toute première variante de toutes les cryptomonnaies, le Namecoin, a tenté d’utiliser une blockchain semblable à celle du Bitcoin pour fournir un système d’enregistrement de noms ou les utilisateurs pouvaient enregistrer leurs noms et d’autres données dans une base de données publique. Le cas d’utilisation le plus cité est celui de système DNS, pour mapper les noms de domaines comme celui de « bitcoin.org » (ou dans le cas de Namecoin’s, bitcoin.bit ») avec l’adresse IP correspondante. Les autres cas d’utilisation inclus l’authentification d’email et potentiellement des systèmes d’authentification plus avancés. ci-après un contrat basique pour fournir un système d’enregistrement de nom tel que celui de Namecoin ou d’Ethereum :

def register(name, value):
if !self.storage[name]:
self.storage[name] = value

Le contrat est très simple ; il s’agit simplement d’une base de données dans le réseau Ethereum qui peut être abondée mais ne peut pas être modifiée ou supprimées. Tout le monde peut enregistrer une nom avec une valeur, et cet enregistrement est alors définitif. Un système de contrat d’enregistrement de noms plus sophistiqué sera également doté d’une fonction « clause » qui permettra à d’autres contrats de l’interroger ainsi qu’un mécanisme pour le propriétaire (par exemple le premier à avoir déposer le nom) du nom pour changer la valeur associée ou transmettre la propriété. Il peut même être ajouté un système de réputation ou une fonctionnalité de de confiance web par dessus.

Stockage de fichiers décentralisé

Au cours des dernières années, un certain nombre de start-up de stockage de fichiers en ligne ont vu le jour, la plus importante étant Dropbox. Ces start-ups ambitionnent de permettre aux utilisateurs de télécharger une sauvegarde de leur disque dur et d’accéder à leur sauvegarde en ligne en échange d’une redevance mensuelle. Cependant, à ce stade, le marché du stockage de fichiers est souvent relativement inefficace ; un coup d’œil rapide sur différentes solutions existantes montre que, en particulier au niveau des 20-200 Go il n’y a  ni quotas gratuits, ni réductions de niveau entreprise. Les prix mensuels pour les frais de stockage de fichiers traditionnels sont tels que vous payez mensuellement plus que le coût du disque dur.

Les contrats Ethereum peuvent permettre le développement d’un écosystème de stockage de fichiers décentralisé, où les utilisateurs individuels peuvent gagner de petites quantités d’argent en louant leur propre disque dur et l’espace inutilisé qui peut être utilisé pour diminuer drastiquement le coûts du stockage de fichiers.
La  dispositif clé sous-jacent est ce que nous avons appelé le « contrat décentralisé Dropbox ». Ce contrat marche de la manière suivante. Tout d’abord, on sépare la donnée cible en blocs en encryptant chaque bloc pour le sécuriser en construisant un arbre de Merkel. On crée alors un contrat avec pour règle que tous les N blocs le contrat va prendre un index aléatoire dans l’arbre de Merkel (en utilisant le hash du bloc précédent, accessible depuis le code du contrat, comme source de donnée aléatoire) puis donner X ether à la première entité qui fournit une transaction avec une vérification de paiement comme preuve de propriété simplifiée du bloc pour cet index particulier de l’arbre. Quand un utilisateur veut re-télécharger son fichier il peut utiliser un protocole de canal de micropaiement (ex. payer un szabo par 32 kilobytes) pour récupérer le fichier ; l’approche la plus efficace en termes de coûts pour le payeur et de ne pas publier la transaction jusqu’à la fin, en remplaçant la transaction avec une légèrement plus lucrative avec le même nonce tous les 32 kilobytes.
Une propriété importante du protocole est que, bien qu’il semble a priori que l’on doivent faire confiance à plusieurs nœuds choisis au hasard pour ne pas décider d’effacer le fichier, on peut réduire ce risque à quasiment zéro en découpant le fichier en plusieurs morceaux via un partage secret et une vérification par le contrat que chaque morceau du fichier est en possession du node. Si un contrat continue à payer de l’argent cela fournit un preuve cryptographique que quelqu’un est toujours en train de stocker le fichier.

Decentralized Autonomous Organizations

Le concept général d’organisation autonome décentralisée (ndt : DAO) est qu’une entité virtuelle avec un certain nombre de membres et d’actionnaires avec par exemple une majorité de 67%, a le droit de dépenser les fonds de l’entité et de modifier son code. les membres vont collectivement décider de comment l’organisation doit allouer les fonds. Les méthodes d’allocation des fonds d’une DAO vont des primes, aux salaires jusqu’à des mécanismes plus exotiques comme une monnaie interne pour récompenser le travail. Pour l’essentiel cela réplique les règles et attributs juridiques d’une entreprise traditionnelle ou d’un organisme à but non lucratif mais en utilisant seulement la technologie cryptographiqe de la blockchain pour son application. Jusqu’à aujourd’hui l’essentiel des discussions ont portées autour du modèle capitaliste d’une DAC « Decentalized Autonomous Corporation( nd t: entreprise décentralisées autonome), avec des actionnaires qui reçoivent des dividendes et des actions négociables ; une alternative qui pourrait être décrite comme une « decentralized autonomous community » (ndt : communauté autonome décentralisée), verrait tous ces membres avoir un poids de vote égal dans la prise de décision et requerrait un accord de 67% des ses membres pour ajouter ou enlever un membre. L’exigence sous-jacente qu’une personne ne peut avoir adhérer qu’une devrait être appliquée collectivement par le groupe.

Un manière générique de coder une DAO de ce type serait la suivante. La conception la plus simple est tout simplement un morceau de code auto-modifié qui change si deux tiers des membres sont d’accord sur ce changement. Bien que le code soit théoriquement immuable, on peut facilement contourner ce problème et créer une évolutivité de facto en divisant le de code en lots fonctionnels unitaires gérés dans des contrats distincts, dont l’adresse d’appel est stockée dans un entrepôt qui lui est modifiable. Dans une mise en œuvre simple d’un tel contrat de DAO, il y aurait trois types de transaction, identifiées par les données fournies dans la transaction :

  • [0,i,K,V] pour enregistrer à l’index i une proposition pour changer l’adresse à l’index de stockage K de l’entrepôt par la valeur V
  • [0,i] pour enregistrer les votes en faveur de la proposition i
  • [2,i] pour finaliser la proposition i si le nombre suffisant de votes a été atteint

Le contrat aurait des clauses spécifiques pour chaque type de transaction. Il maintiendrait un registre de tous les changements intervenus dans l’entrepôt de stockage ainsi que la liste de ceux qui ont votés pour ces changements. Il aurait également une liste de tous les membres A chaque fois qu’un changement atteint une majorité des deux tiers des votants la transaction de finalisation exécute le changement. Une version plus sophistiquée posséderait également une gestion des capacités de votes comme envoyer une transaction, ajouter et retirer un membre.Elle serait également dotée d’un système démocratiquement fluide de délégation de vote (par exemple je peux déléguer mon vote à un tiers et cette assignation est transitive si A désigne B et B désigne C alors C peut voter pour A). Cette conception permettrait à la DAO de grandir de manière organique comme une communauté décentralisée en permettant à ses membres de déléguer la tâche de filtrage des nouveaux entrants à des spécialistes, bien qu’à la différence des systèmes existants les spécialistes peuvent facilement changer au cours du temps en fonction des orientation des membres de la communauté.
Un autre modèle serait une entreprise décentralisée où chaque compte peut avoir zéro ou plusieurs actions et où les deux tiers de leurs actions sont requis pour prendre une décision. Un structuration complète impliquerait une fonction de gestion d’actifs, la capacité pour émettre une offre d’achat ou de vente d’actions et la capacité d’accepter ces offres (de préférence avec un mécanisme automatique d’appariement intrinsèque au contrat). La délégation existerait également sur le mode démocratique fluide généralisant ainsi le concept de « conseil d’administration ».

Autres applications

  1. Compte épargne. Supposons que Alice veuille garder ses fonds en sécurité mais qu’elle redoute de perdre ou de se faire pirater sa clef de cryptage privée. En ce cas elle place des ethers dans un contrat avec Bob, une banque, comme suit :
    • Alice toute seule peut retirer un maximum de 1% du fond par jour.
    • Bob tout seul peut retirer un maximum de 1% du fond par jour, mais seule Alice a le droit de couper l’habilitation de retrait de Bob via une transaction.
    • Ensemble Alice et Bob peuvent retirer ce qu’ils veulent.

    Normalement, 1% par jour est suffisant pour Alice et si Alice veut retirer plus elle peut contacter Bob pour avoir son aide. Si la clef d’Alice est compromise elle se met d’urgence en relation avec Bob pour virer les fonds sur un nouveau contrat. Si elle perd sa clef Bob peut sortir les fonds. Si Bob s’avère véreux Alice peut désactiver son habilitation à retirer.

  2. Assurance récoltes. Il est facile de créer un produit financier dérivé en utilisant une source de données météo à la place d’un indice de prix. Si un fermier de l’Iowa achète un produit dérivé qui le couvre contre le risque de manque de précipitation dans l’Iowa, alors en cas de sécheresse le fermeir recevra autoamtiquement de l’argent et s’il ya suffisamment de pluies alors le fermier sera content car les récoltes seront bonnes. Ceci peut-être généraliser aux divers cas de catastrophes naturelles
  3. Flux de données décentralisé. Pour les contrats financiers différentiels (ndt. CFD), il est déjà possible de décentraliser la source de données via un protocole appelé « ShellingCoin« . ShellingCoin fonctionne basiquement de la manière suivante : N parties mettent dans le système la valeur d’une donnée (ex.taux de change ETH/USD), les valeurs sont triées et chacun entre le 25ème et le 75ème pourcentage obtient un jeton comme récompense. Tout le monde a intérêt à fournir la même réponse que tous les autres et la seule valeur sur laquelle un grand nombre d’acteur peut dans la pratique se mettre d’accord est par défaut : la vérité. Cela crée un protocole décentralisé qui peut théoriquement fournir un certain nombre de valeurs incluant le change ETH/USD, la température à Berlin ou encore le résultat spécifique d’un calcul informatique complexe.
  4. Entiercement multi-signatures intelligent. Bitcoin permet les contrats de transaction multi-signatures o, par exemple, 3 de 5 clefs données peuvent dépenser les fonds. Ethereum permet une granularité plus fine. Par exemple 4 des 5 peuvent dépenser tout le montant, 3 des 4 peuvent dépenser 10% par jour et 2 des 5 peuvent dépenser 0,5% par jour. De plus le multisig Ethereum est asynchrone – deux des tiers peuvent enregistrer leur signatures sur la blockchain à différents moment et la dernière signature enverra automatiquement la transaction.
  5. Cloud computing. La technologie de l’EVM peut également être utilisée pour créer un environnement de calcul vérifié, en permettant à ses utilisateurs de demander à d’autres d’effectuer les calculs et en option de fournir la preuve que le calcul a été correctement effectué selon des points de contrôle aléatoires. Ceci permet la création d’un marché du cloud computing ou chacun des utilisateur peut participer avec son desktop, son laptop ou un serveur spécialisé et doté de points de vérification sécurisés via des dépots de garantie qui assure que le système est fiable (par exemple les noued ne peuvent tricher de manière rentable). Bien qu’un tel système ne soit pas souhaitable pour tous les types de calculs, les calculs qui requiert un niveau élevé de communication inter processeur par exemple ne peuvent pas être mener à bien facilement au travers d’un cloud ; d’autres types de calculs sont a contrario aisément parallélisables,des projets comme [email protected], [email protected] et les algortimes génétiques peuvent facilement être implémentés sur une tel plateforme.
  6. Jeu en mode peer to peer. Tous les protocoles de jeu, tels que le Cyberdice de Franck Satjano et Richard Clayton, peuvent être implémentés sur la blockchain Ethereum. Le protocole de paris le plus simple est un contrat différentiel sur le prochain hash de la Blockchain et de plus avancés peuvent être créer par dessus en un service de paris avec quasiment aucune redevance et sans possibilité de triche.
  7. Marché de la prédiction. Des marchés de prédictions pourvus d’un oracle ou d’un ShellingCoin sont aisément programmables, et les marchés de prédiction avec un ShellingCoin pourrait se révéler être la première application de masse d’une futarchy en tant que protocol de gouvernance d’une organisation décentralisée.
  8. Places de marché décentralisées On-chain, utilisant l’identité et la réputation comme système de base.

Point de vigilance et divers

Implémentation GHOST modifiée

Le protocole GHOST pour « Greedy Heaviest Observed Subtree » (GHOST) (ndt ou sous-arbre gourmand observé le plus lourd, je propose GOUL pour GOUrmand Lourd en français :-)) est une innovation introduite la première fois par Yonatan Sompolinsky et Aviv Zohar en décembre 2013. La motivation dérrière GHOST est le fait que les blockchains avec un temps de confirmation rapide souffrent actuellement d’une sécurité réduite due à un taux de péremption élevé. Comme les blocs mettent un certain temps à se propager au travers du réseau si un mineur A mine un bloc et un mineur B mine un autre bloc avant que le bloc du mineur A se soit propagé alors le bloc du mineur sera gaché et ne contribura pas à la sécurité du réseau. En plus de cela il y un problème de centralisation : si un mineur A est un pool de minage avec 30% de capacité de calcul de hash ou hashpower et B n’a que 10% de hashpower, A aura un risque de produire un bloc périmé 70% du temps (puisque le reste des 30% du temps A produit le tout dernier bloc et obtiendra donc les données à miner immédiatement) tandis que B aura un risque de produire un bloc périmé 90% du temps. Donc si l’interval de temps entre 2 blocs est suffisament court pour que le taux de péremption soit haut A aura une efficacité substantiellement plus impoortante par la seule vertue de sa taille. Avec ces deux effets combinés, les blockchains qui produisent des blocs rapidement sont enclines à induire l’émergence d’un un pool de minage qui aura un pourcentage du haspower du réseau suffisant pour prendre le contôle du processus de minage.
Comme cela est décrit par Sompolinsky et Zohar, GHOST résout le premier problème conernant la sécurité du réseau en incluant les blocs périmés dans le calcul de la chaine la plus longue ce qui veut dire que ce ne sont pas seulement les parents et les autres ancêtres du bloc mais également les descendants périmés des ancêtres du bloc (dans le jargon Ethereum, les « oncles ») qui sont ajoutés au calcul qui détermine quel bloc à la plus grande preuve de travail. Pour rsoudre le second problème du biais de centralisation nous allons au-delà du protocole décrit par Sompolinsky et Zohar et nous fournissons également une récompenses pour les blocs périmés : un bloc périmé reçoit 87,5% de la récompense de base et se neveux qui inclus le bloc périmé reçoivent les 12,5% restants. Les primes de transaction dans tous les cas ne sont pas décernées aux oncles.
Ethereum implémente une version simplifiée de GHOST qui ne remonte pas au-delà de 7 niveaux. La définition spécifique est la suivante :

  • Un bloc doit spécifier un parent et 0 ou plus oncles
  • Un oncle inclus dans un bloc B doit avoir les propriétés suivantes :
    • Il doit être un fils direct de kièmegénération d’ancêtres de B tel que 2 <=k <= 7.
    • Il ne peut être un ancêtre de B
    • Un oncle doit être un en-tête de bloc valide mais n’a pas besoin d’avoir été vérifié auparavant ni d’avoir été validé
    • Un oncle doit être différent de tous les oncles déjà inclus dans les blocs précédents et de tous les autres oncles inclus dans le même bloc (non-double-inclusion)
  • Pour chaque oncle U dans le bloc B, le mineur de B obtient une prime additionnelle de 3,125% ajoutée à sa récompense en unité monétaire de base et le mineur de U reçoit 93,75% de la récompense standard.

Cette version limitée de GHOST avec des oncles incorporables sur seulement 7 générations a été utilisée pour deux raisons. Premièrement, un GHOST illimité impliquerait trop de complexité dans les calculs pour déterminer quel oncle est valable pour un bloc donné. Deuxièmement un GHOST illimité avec compensation financière comme celle d’Ethereum ôterait tout intérêt pour le mineur à miner sur la chaine principale et non pas la chaine d’un éventuel pirate.

Primes

Parce que chaque transacation publiée dans la blcokchain impose au réseau son coût de téléchargement et de vérification, il est nécessaire d’avoir un mécanimes de régulation qui implique généralement des frais (ou prime selon le point de vue) de transactions pour éviter tout abus. L’approche par défaut, utilisée dans Bitcoin, est basée sur des frais librement proposés, en s’appuyant sur les mineurs comme arbitre en fixant dynamiquement un minimum. Cette approche a été très favaorablement accueillie dans la communauté Bitcoin notamment parce qu’elle est basée sur la régulation par le marché, qui détermine le prix en fonction de l’offre et de la demande entre les fournisseurs mineurs et les soumissionnaires des transactions. Le problème avec ce type de raisonnement est que le traitement des transcation n’est pas un marché. Bien qu’il soit intuitivement séduisant de concevoir la transaction comme un service que le mineurs rend à l’emetteur, en réalité chaque transaction qu’un mineur inclue va devoir être calculée par tous les noeuds du réseau, si bien que la majeure partie des coûts de traitement de la transaction est pris en charge par des tiers et non par le mineur qui prend la décision de l’inclure ou non. Par conséquent, un problème de « tragédie des communs » est très susceptibles de se produire.
Mais cette faille dans le mécanismes basé sur le marché s’annule comme par magie quand on se place dans l’hypothèse simplificatrice erronée suivante :

  1. Une transaction donne lieu à k et offre la récompense kR à tout mineur qui l’inclue où R est donné par l’émetteur et où k et R sont grossièrement évaluables par le mineur avant de l’inclure.
  2. Une opération à un coût de calcul de C pour n’importe quel noeud (c-ad-d que tous les noeuds ont le même rendement).
  3. Il y a N noeud qui minent chacun avec exactement la même puissance de calcul (c-a-d 1/N du total)
  4. Il n’existe pas de noeud complet qui ne mine pas.

Une mineur effectuera la transaction s’il peut s’attendre à ce que le prime soit supérieure au coût. Donc à ce que la prime soit de kR/N puisque le mineur a 1/N chance de résoudre le bloc suivnat est que coût de calcul du bloc est kC. par conséquent les mineurs vont inclure les transactions où kR/N > kC ou R > NC. Notons que R est le frais par opération prévue par l’émetteur et donc une borne inférieur sur le bénéfice escompté par l’émetteur sur la transaction et d’autre part notons que NC est le coût de traitemnt pour le réseau tout entier. par conséqueent les mineurs vont avoir tendance à inclure seulement les transactions pour lesquelles le bénéfice utile total excède le coût.
Dans la réalité il y a cependant plusieurs écarts importants avec l’hypothèse précédente :

  1. le mineur paie un coût plus élevé pour la transaction que les autres noeds de vérification, uisque le temps de calcul plus long bloque la propagation et accroît le risque que le bloc devienne périmé
  2. Il existe bien des noeuds complet qui ne minent pas.
  3. La répartition du coût de minage est radicalement inégalitaire dans la pratique.
  4. DLes spéculateurs, les ennemies politiques et le s fous dont la seul but est de causer du mal au réseau existent et ils peuvent créer des contrats dont le coût est très inférieur à celui des autres noeds de vérification à dessein.

Le point (1)entraine une tendance pour le mineur à inclure moins de transaction et le point (2) augmente NC, par conséquent ces deux effets s’annulent partiellement mutuellement. les points (3) et (4) sont le principal problème. Pour le résoudre (ndt dans Ehteruem) nous instituons une limite flottante : aucun bloc ne peut avoir plus d’opération que la moeyenne mobie exponentielle à long-terme fois BLK_LIMIT_FACTOR. Précisement :
blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)

BLK_LIMIT_FACTOR et EMA_FACTOR sont des constantes qui sont à ce jour définies sur les valeurs 65536 et 1,5 mais qui pourront évoluer après analyse complémentaire dans le futur.

Il y a un autre facteur de démotivation pour le traitement des gros blocs dans Bitcoin : les gros blocs vont mettre plus de temps à se propager t ont ainsi une probabilité plus élevée de se périmer. Dans Ethereum les bloc très consommateurs en gas peuvent également mettre plus de temps à se propager parcequ’ils sont physiquement plus gros et qu’il mettent plus de temps à se valider. Ce facteur de démotivation au traitement est une problème significatif dans Bitcoin mais beaucoup moins dans Ethereum du fait du GHOST protocol par conséquent s’appuyer sur la limite de bloc fournit une base plus stable.

Traitements informatiques et aspect Turing-complet

Un point fondamental est que la machine virtuelle Ethereum est Turing-complet, ce qui signifie que le code EVM permet de programmer tous les calculs concevables y compris des boucles infinies. Le code EVM permet deux types de boucles. Tout d’abord il y a une instruction JUMP qui autorise un programme à faire un saut en arrière dans les instructions du code et une instruction JUMPI pour faire des saut conditionnels ce qui permet des instructions de type while x < 27: x = x * 2. Deuxièmement les contrats peuvent appeler d’autres contrats ce qui peut entrainer une boucle par récursivité. Ceci entraine naturellement un problème de sécurité est-ce qu’un utilisateur malveillant peut faire tomber les nœuds et les mineurs en les forçant à entrer dans une boucle infinie ? Ce risque connu en informatique comme problème de l’arrêt ou problème de la décision est qu’il n’y a pas de moyen de savoir si oui ou non une un programme données ne se terminera jamais.
Comme nous l’avons décrit dans la section sur l’état de transition notre solution consiste à exiger que la transaction postule un nombre maximum d’étapes de calcul et que si l’exécution prend plus de temps l’opération est inversée mais que les frais sont payés quand même. Les messages fonctionnent de la même manière. Pour comprendre ce qui a motivé ce choix de solution considérons les exemples suivants :

  • L’attaquant crée un contrat qui implémente une boucle infinie et lance alors une transaction quia ctive la boucle chez le mineur. Le mineur va traiter la transaction et attendre que’elle épuise son gas. Bien que l’éxecution de l’instruction arrive à court de gas, la transaction reste valideet le mineur encaisse les frais pour chaque étape de l’éxécution des calculs.
  • L’attaquant crée une boucle infinie très longue dans le but de forcer le mineur à executer le calcul pour un temps si long que le temps qu’il soit achevé plusieurs nouveau bloc soit publiés et qu’il soit impossible au mineur d’inclure la transacation dans un bloc pour pouvoir réclamer ses frais. Néanmoins l’attaquant aura eu l’obligation de donner une valeur STARTGAS pour limiter le nombre d’étape de calculs que l’execution nécessite, de sorte que le mineur saura d’avance que le temps d’execution est execessif.
  • L’attaquant repère un contrat incluant dans son code un appel de typesend(A,contract.storage[A]); contract.storage[A] = 0, et il envoie une transaction avec juste assez de ga pour executer la première étape mais pas la seconde (c-a-d faire un retrait mais sans laisser le solde du compte diminuer d’autant).L’auteur du contrat n’a pas à s’inquiéter de se protéger contre ce genre de contrat parce que si l’éxecution stoppe à mi-parcours alors elle est automatiquement inversée.
  • Un contrat financier fonctionne en prenant la moyenne des données de 9 flux propriétaires afin de réduire le risque. L’attaquant prend le contrôle d’un des 9 flux qui est conçut pour être modifiable via un variable d’adresse d’appel comme décrit dans le paragraphe sur les DAO et le modifie pour lui faire éxécuter une boucle infinie afin de faire en sorte que toute tentative de retrait de fonds du contrats va avorter faute de gas. Dans tous les cas il suffit au contrat financier de prévoir une limite de gas sur le message pour éviter ce problème.

L’alternative au modèle Turing-complet et le modèle Turing-incomplet où les primitives JUMP et JUMPI n’existent pas et où une seule instance du contrat peut exister dans la pile d’appel à un instant T. Avec ce système le système de frais et les incertitudes autour de sons efficacité ne serait peut-être pas nécessaire car le coût d’éxecution du contrat serait caper par sa taille. De plus le modèle le fait que le langage ne soit pas Turing n’est pas une limite insurmontable ; de tous les exemples de contrats que nous avons conçut un seul nécessitait une boucle et même cette boucle pourrait être remplacé en répétant 26 fosi une seule lingne de code. En considérent les implications d’un lagage Turing-complet et les bénéfices limités qu’il apporte pourquoi ne passimplement utilise runelangage non turing-complet? En réalite l’incomplétude du langage n’est pas une solution, pour comprendre pourquoi considérons les contrats suivants :

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)

Maintenant envoyons une transaction à A ainsi en 51 transaction nous avons un contrat qui prend 250 étapes de calcul. Les mineurs pourraient essayer de détecter une telle bombe logique en maintenant une valeur associée à chaque contrat qui spécifierait le nombre maximal d’étapes de calculs qu’il peut prendre et en calculant cette valeur de manière récursives pour les contrats qu’il pourrait appeler lui-même. Mais cela requerrait que les mineurs interdisent les contrats qui peuvent créer d’autres contrats (puisque la création et l’éxecution des 26 contrats de l’exemple précédent pourrait facilement être embarquée dans un seul contrat.) D’autre part un autre point problèmatiqueet que le champs d’adresse d’un message est une variable et que donc il n’est même pas possible de dire quel autre contrat un contrat donnée va appeler dans le futur. Par conséquent l’un dans l’autre nous aboutissons à une conclusion surprenante : le modèle Turing-complet est facile à gérer et son absence et très difficile à gérer à moins d’avoir mis en place exactement les même contrôles mais en ce cas pourquoi se priver du modèle Turing-complet?

La monnaie et son émission

Le réseau ethereum inclus sa propre monnaie, l’ether, qui sert le double objectif de fournir une couche primaire de liquidité pour assurer l’efficacité des échanges entre différents types d’assets digitaux et encore plus important fournit une mécanisme de paiement des frais de transaction. Par commodité et pour éviter toute discussion ultérieure oiseuse (cf. le débat actuel sur le mBTC/UBTC dans Bitcoin) les dénominations suivantes ont été labellisées :

  • 1: wei
  • 1012: szabo
  • 1015: finney
  • 1018: ether

Considérons cela comme une version élargie de la notion de « dollar » et de « cents » ou de « BTC » et « satoshi ». A court terme nous escomptons que l' »ether » sera utilisé pour les transactions ordinaires, le « finney » pour les micro transactions, le « szabo » et le « wei » pour les discussions techniques autour des frais et de la mise en œuvre du protocole. Les autres coupures pourraient devenir utiles plus tard mais ne devraient pas être implémentées dans les logiciels clients à ce stade.
Le modèle d’émission de la devise sera le suivant:

  • Ether sera proposé dans une vente de devise au prix de 1000-2000 ether par BTC, un mécanisme destiné à financer l’organisation Ethereum et à payer pour les développement qui a déjà été utilisé avec succès par d’autres plateformes comme Mastercoin ou NXT. Les premiers acheteurs bénéficieront de remise plus importantes. les BTC reçu lors de la vente serviront dans leur intégralité à payer les salaires et les primes des éveloppeurs et seront investis dans divers projetsde l’écosystème Ethereum qu’ils soient à but lucratifs ou non.
  • 0.099x du montant total des ventes (60102216 ETH) sera alloué à l’organisation pour récompenser les premiers contributeurs et payer les frais en ETH engagés avant le bloc de genèse.
  • 0.099x du montant total vendu sera maintenu comme une réserve à long terme.
  • 0.26x du montant total des ventes sera allouée aux mineurs annuellement et à jamais à partir de là.

 

Group Au démarrage Après 1 an Après 5 ans
Unités monétaires 1.198X 1.458X 2.498X
Acheteurs 83.5% 68.6% 40.0%
Reserve dépensée avant la vente 8.26% 6.79% 3.96%
Reserve après la vente 8.26% 6.79% 3.96%
Mineurs 0% 17.8% 52.0%

Taux de croissance à long terme de l’approvisionnement de la masse monétaire en pourcentage

En dépit de l’aspect linéaire de l’émission des coupures le taux de croissance de l’apport monétaire tend vers zéro.
Les deux choix principaux du modèle ci-dessus sont : (1) l’existence et la taille de la dotation initiale, (2) l’existence d’un apport linéaire et permanent par opposition au plafonnement de la masse monétaire de Bitcoin. La justification de la dotation initiale est la suivante. Si la dotation initiale n’existait pas et que l’émission monétaire linéaire était réduite à 0,217x pour fournir le même taux d’inflation alors la quantité totale d’ether serait inférieur de 16,5% et de ce fait chaque unité aurait une valorisation de 19,8% de plus. Par conséquent en conservant cet équilibre 19,8% d’ether en plus aurait mis sur le marché, pour faire en sorte que chaque unité ait la même valeur que dans la situation précédente. l’organisation aurait donc 1,198x BTC en plus qui peut-être considéré comme étant constitué de 2 parties : les bitcoins originaux et la part additionnel de 0,198x. Par conséquent la situation est exactement la même qu’avec la dotation initiale mais avec une différence important l’organisation ne déient que des BTC et n’est pas encouragée à soutenir la valeur de l’ether.
Le modèle de croissance linéaire de l’approvisionnement réduit le risque d’avoir ce que certains considère comme une concentration excessive de richesse dans Bitcoin. Cela donne à chacun mainteant et dans le futur une possibilité équitable d’acquérir des unités monétaires tout fermement l’intérêt d’obtenir et de détenir des ether puisque le « le taux de croissance de l’approvisionnemnt » en pourcentage tend toujours vers zéro à terme.
Nous émettons également l’hypothèse que des coupures sont toujours perdues au fil du temps du fait de négligences, de la mort, etc. Et ces pertes peuvent être modélisées comme un pourcentage annuel de l’approvisionnement en liquidité de sorte que la monnaie réellement en circulation se stabilise à une valeur égale à l’émission annuelle divisée par le pourcentage de perte (ex. avec un pourcentage de perte de 1%, chaque fois que le l’approvisionnement atteint 26x alors 0,26x sont minés chaque année et O,26x sont perdus créant ainsi un équilibre).
Notons que dans le futur il est probable qu’Ethereum basculera vers un modèle proof-of-stake par sécurité, ce qui réduira la nécessité d’émission d’argent vers un ratio entre zéro et 0,05x par an. Dans l’hypothèse où l’organisation Ethereum perde ses fonds ou pour tout autre raison disparaisse, nous laissons ouvert un « contrat social » : tout le monde à le droit de créer une future version d’Ethereum avec pour seule condition que la quantité d’ether soit au plus égale à 60102216*(1,198+0,26*n) où n est le nombre d’année après la création du bloc d’origine. Les versions candidates qui ne seraient pas confrormes à la règle pourraient être « forkées » de amnière justifiée en une version conforme.

Centralisation du minage

L’algorithme de minage Bitcoin implique que les mineurs calculent le SHA256 d’une version légèrement modifié du header des blocs des millions de fois pour finir par avoir une version dont le hash soit inférieur à la valeur de la cible (au moment de la rédaction 2192). Néanmoins l’algorithme est vulnérable à deux formes de de centralisation. La première est que l’écosystème de minage a finit par être dominé par des ordinateurs conçut sur la base de chipset ASICs (application-specific integrated circuit) et donc des milliers de fois plus efficaces pour effectuer la tâche spécifique de minage. Ce qui signifie que le Bitcoin n’est plus ce graal décentralisée et et égalitaire qui requerrait des millions de de dollar de capital pour participer en ayant une vrai influence. La seconde forme de centralisation est que la plupart des mineurs n’effectuent plus la valiation de leur bloc localement délèguent à un pool centralisé la fourniture des en-têtes de blocs. Ce problème est sans doute le pire car au moment où nous écrivons ces lignes 3 pools de minages contrôlent indirectement 50% de la puissance de calcul du réseau Bitcoin même si ce danger est atténuer par le fait que les mineurs pourraient changer de pools si une un des principaux ou une coalition tentait une attaque 51%.
L’objectif actuel d’Ethereum est d’utiliser un algorithme de minage où les mineurs sont tenus d’extraire des données aléatoires de l’état, effectuer aléatoirement le calcul de transactions dans les N derniers blocs de la blockchain et de retourner le hash du résultat. Ce qui procure deux bénéfices importants : premièrement les contrats Ethereum peuvent inclure n’importe quel type de calculs donc un ASIC Ethereum serait un ASIC pour des calculs génériques par ex. un meilleur CPU. Deuxièmement le minage nécessite l’accès à la totalité de la blockchain ce qui force les mineurs à la stockée en intégralité et à minima d’être capable de vérifier chaque transaction. Cela élimine le besoin de pool de minage centralisé car bien qu’un pool de minage puisse toujours servir l’objectif légitime d’éliminer le caractère aléatoire de l’obtention de la récompense, cette fonction peut parfaitement être assumer par un pool peer-to-peer non centralisé.
Ce modèle n’a pas été testé, et il peut y avoir des difficultés le long du chemin pour éviter certaines optimisations intelligentes comme l’exécution du contrat comme un algorithme de minage. Cependant, une caractéristique intéressante de cet algorithme est notamment qu’il permet à quiconque d’«empoisonner le puits », en introduisant un grand nombre de contrats dans le blockchain spécifiquement conçus pour contrecarrer certains ASICs. Les incitations économiques existent pour les fabricants d’ASIC à utiliser un tel procédé pour attaquer leur concurrent. Ainsi, la solution que nous développons est finalement une solution d’adaptation économique humaine plutôt que purement technique.

Scalability

Une des préoccupation habituelle au sujet d’Ethereum est le problème de l’évolutivité (ndt ou scalabilité au sens informatique d’accroissement de la taille). Comme Bitcoin, Ethereum souffre de cette faille qui est que chaque transaction doit être calculée par l’ensemble des noeuds du réseau. Avec Bitcoin la taille de la blockchain actuelle se situe autour de 15 GB et grandit d’environ 1 MB par heure. Si le réseau Bitcoin devait traiter les 200 transactions par seconde du réseau VISA il grandirait 1 MB toutes les trois secondes (1 GB par heure, 8TB par an). Ethereum est susceptible de souffrir d’un modèle de croissance similaire aggravé par le fait qu’il y aura de nombreuses applications qui tourneront sur la blockchain et non pas la seule monnaie comme avec Bitcoin mais ceci sera amélioré par le fait qu’un nœud complet d’Ehtereum ne nécessite de stocker que l’état au lieu dela blockchain complète.
Le problème avec une telle taille de blockchain est le risque de centralisation. Si la taille de la blockchain augmente jusqu’à mettons 100 TB, alors le scénario probable serait que seul un petit nombre de grosses entreprises seraient capables de faire tourner les noeads complets et tous les utilisateurs communs utiliseraient les noeud SPV légers. Dans une telle situation le risque augmente que les nœuds complets s’entendent pour tricher de manière profitable (par exemple changer la récompense de bloc, se donner des BTC). Les nœud s léger s n’auraient aucun moyen de détecter cela immédiatement. Bien sûr au moins un nœud honnête existerait surement et après quelques heures information sur la fraude se répandrait au travers de canaux comme Reddit, mais à ce stade il serait trop tard : il faudrait que les utilisateurs standards s’organise en un effort pour blacklister les nœuds tricheurs un problème de coordination massif et insoluble à une échelle semblable à celle de contrer une attaque de 51% réussie. Dans le cas de Bitcoin, c’est actuellement un problème, mais il existe une modification de la blockchain suggérée par Peter Todd, qui permettra d’atténuer ce problème.
À court terme, Ethereum utilisera deux stratégies complémentaires pour faire face à ce problème. Tout d’abord, en raison des algorithmes d’extraction de base de la blockchain, tous les mineurs seront forcés d’être un noeud complet, créant une limite inférieure sur le nombre de nœuds complets. Deuxièmement et plus important encore, nous allons inclure un état intermédiaire de la racine de l’arbre dans le blockchain après le traitement de chaque transaction. Même si la validation de bloc est centralisée, aussi longtemps qu’un nœud de vérification honnête existe, le problème de la centralisation peut être contournée via un protocole de vérification. Si un mineur publie un bloc invalide, ce bloc est soit mal formaté, soit l’état S[n] est incorrecte. Puisque S[0] est connu pour être correct, il doit y avoir un état antérieur S[i] qui est incorrect où S[i-1] est correct. Le noeud de vérification fournirait l’indice i, avec une « preuve d’invalidité » composé du sous-ensemble des nœuds de l’arbre de Patricia qui ont besoin de traiter APPLIQUER (S [i-1], TX [i]) -> S [i]. Les nœuds seraient en mesure d’utiliser ces noeuds pour exécuter cette partie du calcul, et constater que le S[i] généré ne correspond pas au S[i] fourni.

Une autre attaque, plus sophistiqué, impliquerait des mineurs malveillants publiant des blocs incomplets, pour lesquels il n’existe même pas l’information complète pour déterminer si oui ou non les blocs sont valides. La solution à cela est un protocole à challenge de réponse : les nœuds de vérification émettent un «challenge» sous la forme d’indices de transaction cible, et lors de la réception d’un nœud par un nœud léger celui-ci traite le bloc comme « untrusted » jusqu’à ce qu’un autre nœud, que ce soit d’un mineur ou d’un autre vérificateur, fournisse un sous-ensemble de nœud de Patricia comme une preuve de validité.

Conclusion

Le protocole Ethereum a été à l’origine conçu come une version améliorée dune cryptomonnaie fournissant des services avancés comme l’entiercement, les limites de retrait, les contrats financiers, un marché pour le jeu et d’autres du même genre au travers d’un langage de prgrammation très générique. Le protocole Ethereum n’implémente pas en lui-même aucune de ces applications mais l’existence l’un langauge de programmation Turing-complet implique que l’on peut en théorie créer des contrats arbitraires pour n’iporte qu’elle transaction ou applicationCe qui est encore plus intéressant à propose d’Ethereum c’est que le protocole va bien au delà d’une monnaie. En effet des protocoles comme le stockage de fichiers décentralisé, les calculs inforamtiques décentralisés, les marchés de la prédiction parmi des douzaines de concpets de ce type ont un potentielpour acroitre substantiellement l’efficacité de l’industrie inforamtique et fournissent boost massif aux autres protocoles peer-to-peer en Finalaleur ajoutant pour la première fois une couche économique; Au final il y a un ensemble substentiel d’applications qui n’ont rien à voir avec l’argent.
Le concept de fonction d’état de transition arbitraire tel qu’implémenté dans le protocole Ethereum donne à la plateforme un potentiel unique; plutôt que d’être, un protocole de type fermé à usage unique destiné à une gamme spécifique d’applications dans le stockage de données, le jeu ou la finance, Ethereum est ouvert par la nature de sa conception même, et nous croyons qu’il est extrêmement bien adapté pour servir de couche fondamentale à un très grand nombre de protocoles financiers et non financiers dans les années à venir.

Notes et lectures complémentaires

Notes

  1. Un lecteur averti notera qu’en réalité une adresse Bitcoin est un hash de la courbe elliptique de la clef publique et non la clef publique elle-même. néanmoins il en fait parfaitement légitime du point de vue de la terminologie cryptographique de se référer au hash de la clef comme à la clef publique elle-même. Tout simplement parce que la cryptographie Bitcoin peut-être considérée comme une signature digitale ad hoc où la clef publique consiste en un hash de l’ECC de la clef publique (ECC pour Elliptic Curve Cryptography (Cryptographie sur les Coubres Elliptiques)), la signature consiste en une concaténation de l’ECC de la clef publique avec l’ECC de la signature et où l’algorithme de vérification implique de de vérifier l’ECC de la clef publique situé dans la signature avec le hash de l’ECC pubkey puis de vérifier l’ECC de la signature contre l’ECC de la clef publique
  2. Techniquement la médiane des 11 blocs précédents.
  3. En interne, 2 et « CHARLIE » sont tous deux des nombres, ce dernier étant encodé en base 256 big-endian. Les nombres peuvent être au moins 0 et au plus 2256-1.

Lectures Complémentaires

  1. Intrinsic value: http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/
  2. Smart property: https://en.bitcoin.it/wiki/Smart_Property
  3. Smart contracts: https://en.bitcoin.it/wiki/Contracts
  4. B-money: http://www.weidai.com/bmoney.txt
  5. Reusable proofs of work: http://www.finney.org/~hal/rpow/
  6. Secure property titles with owner authority: http://szabo.best.vwh.net/securetitle.html
  7. Bitcoin whitepaper: http://bitcoin.org/bitcoin.pdf
  8. Namecoin: https://namecoin.org/
  9. Zooko’s triangle: http://en.wikipedia.org/wiki/Zooko’s_triangle
  10. Colored coins whitepaper: https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit
  11. Mastercoin whitepaper: https://github.com/mastercoin-MSC/spec
  12. Decentralized autonomous corporations, Bitcoin Magazine: http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/
  13. Simplified payment verification: https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification
  14. Merkle trees: http://en.wikipedia.org/wiki/Merkle_tree
  15. Patricia trees: http://en.wikipedia.org/wiki/Patricia_tree
  16. GHOST: http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf
  17. StorJ and Autonomous Agents, Jeff Garzik: http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html
  18. Mike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5Y
  19. Ethereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP
  20. Ethereum Merkle Patricia trees: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree
  21. Peter Todd on Merkle sum trees: http://sourceforge.net/p/bitcoin/mailman/message/31709140/
Share

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.