Lors de notre dernier article, nous avons eu l’occasion de revenir sur l’un des concepts essentiels de l’Ethereum : Le proof of Stake. Pour continuer notre recherche et nos découvertes sur l’Ethereum, nous avons décidé aujourd’hui de nous pencher sur les Smarts Contracts, ou contrats intelligents et notamment la machine virtuelle sur l’Ethereum (EVM).
Sur l’ensemble des éléments plus ou moins techniques composant l’Ethereum, deux briques essentielles sont à la base de cette pile : l’EVM et les contrats intelligents.
La blockchain Ethereum a initialement été créée pour un but unique : rendre consistant entre plusieurs nœuds l'état de sa machine virtuelles. Très rapidement, le concept de monnaie est apparu pour rémunérer les noeud faisant tourner l’EVM car cette machine virtuelle a une particularité inhérente à toutes les mécanismes de programmation distribués : son état doit être consistant entre tous les noeud composant le réseau de l’Ethereum sans avoir aucun serveur maître.
L’EVM créé est une machine virtuelle se voulant être une machine déterministe. Ainsi, deux appels consécutifs se doivent de donner le même résultat si les éléments donnés sont identiques. Cette propriété est absolument nécessaire pour que tous les nœuds dans le réseau puissent consentir à un état de la machine virtuelle constant entre les noeuds en effectuant les mêmes étapes.
Les instructions de la EVM ressemblent à toutes autres instructions d’un processeur classique. Reposant sur une architecture de pile (de profondeur 1024 où chaque élément fait 256-bit), l’EVM définit des opcodes (dont beaucoup parleront aux fans d’assembleurs). La seule différence avec une machine virtuelle plus classique est que chaque opcode a une consommation de gas définie et stable. Ainsi, on connaît le coût de chaque instruction, ce qui est difficilement réalisable avec une machine virtuelle classique.
L’EVM sert notamment à l'exécution de Contrat Intelligent, eux aussi défini sur la blockchain et pouvant être écrit par tous.
L’Ethereum utilise les contrats intelligents depuis sa création, reprenant les principes qu’a pu définir Nick Szabo en 1994. L’objectif d’un smart contrat et de réduire si ce n’est faire disparaître les risques de fraudes liés à un tiers de confiance existant de facto dans un contrat classique.
Prenons un exemple concret pour mieux comprendre les risques face à un contrat classique : vous êtes à la caisse de votre supermarché, le caissier prend votre article et le passe sur sa caisse. Premier problème, rien n'empêche le caissier de ne pas passer l’article, ou de faire passer un autre code bar, la même chose pour vous. Au moment de payer, vous sortez votre carte bancaire et effectuez la transaction, mais le caissier refuse de vous rendre votre objet. Le contrat ici n’a pas été respecté, le contrat étant le fait que vous payez en échange de la possession d’un nouvel objet.
Ceci peut aussi arriver pendant un pari. Disons que vous pariez que vous courez plus vite que votre copain. Vous faites la course, et vous gagnez. Votre copain vous doit maintenant la somme que vous avez parié mais il refuse de vous payer, prétextant que vous avez eu le meilleur côté de la route ou que ces chaussures sont usées. Vous voilà maintenant bien embêtés, vous êtes maintenant essoufflés, tout aussi pauvre qu’avant et avec un ami en moins. C'est ce genre de problème qu’essaye de contrer les smart contrats, en éliminant de l'équation les tiers pouvant faire en sorte de ne pas accomplir leur part dans le contrat.
Il existe aujourd’hui des smarts contrats dans notre quotidien sans qu’on s’en rende compte. Les distributeurs (boissons, bonbons, pommes de terres…) sont aussi des contrats intelligents, car ils nous assurent que contre une somme d’argent, nous obtenions notre friandise.
Dans l’Ethereum, les contrats intelligents sont des bouts de programme, écrits dans un langage puis compilés pour être exécutés sur l’EVM qui se doivent d'être déterministe par conception.
Les contrats intelligents peuvent être exécutés sur n’importe quel nœud composant le réseau de l’Ethereum. Pour ces raisons, et de part sa conception, les contrats intelligents ne peuvent répondre à des événements hors de l’EVM. Supposons un contrat intelligent liant Bob et Alice à un pari. Bob paris le nom du prochain président en France et s’il a raison, Alice lui donnera 10 ETH. S’il a tort, l’inverse se passe. Pour pouvoir fonctionner, ce contrat intelligent a besoin d'accéder à une information a un instant précis située hors de la blockchain. L’aspect déterministe de l’Ethereum empêche ce fonctionnement, car supposons que l’application / l’API hors de la blockchain ne soit pas consistante et réponde ‘Hamilton’ au premier nœud et ‘Perez’ au second nœud, aucun consensus ne pourra être trouvé entre ces deux nœuds. Malgré tout, il est nécessaire que les contrats intelligents et le code exécuté sur l’EVM puissent accéder à des informations hors de la blockchain, notamment pour pouvoir répondre aux cas d’usages précédents.
Pour répondre à ce besoin, l’EVM ingère les données hors de la blockchain. L’Ethereum les appelle les Oracles, ou encore, les Contrats Intelligent hybrides.
Les contrats intelligents hybrides ont pour optique de répondre au besoin de consommer de la donnée disponible uniquement hors de la blockchain et de rendre ces données accessibles aux contrats intelligents dans la blockchain. Pour ce faire, l’architecture classique consiste à créer des contrats intelligents hybrides, composés d’une partie installée sur la blockchain et d’une autre partie, sur un nœud externe chargé d’effectuer les requêtes aux différentes sources de données. Ces données sont ensuite envoyées au contrat intelligent dans la blockchain, maintenant responsable de rendre ces données disponibles pour les autres contrats intelligents. Cette technique peut poser des problèmes.
Ces Oracles, comme définit par l’Ethereum, se doivent de répondre à trois challenges :
L’exactitude des données : La partie du contrat hybride hors de la blockchain doit s’assurer que la donnée mise à disposition est correcte, intègre et a été récupérée auprès d’une source de confiance.
Un oracle ne doit pas influer sur la rapidité d'exécution et la disponibilité d’un autre smart contrat.
L’oracle doit pouvoir lier l’information à sa source et être responsable de la donnée mise à disposition.
EVM Ethereum
Introduction to smart contracts
Smart Contracts
