Dans cet article, nous allons examiner ce que sont les contrats intelligents, quelles en sont les différentes variations, nous familiariser avec diverses plateformes de contrats intelligents, leurs caractéristiques, ainsi que discuter de leur fonctionnement et des avantages qu'ils peuvent offrir. Ce matériel sera très utile pour les lecteurs qui ne sont pas suffisamment familiarisés avec le sujet des contrats intelligents, mais qui souhaitent en comprendre les principes.
Contrat classique vs. contrat intelligent
Avant de plonger dans les détails, examinons à travers un exemple les différences entre un contrat classique, qui est rédigé sur papier, et un contrat intelligent, qui se présente sous forme numérique.
Comment les choses fonctionnaient avant l'apparition des contrats intelligents ? Imaginez un groupe de personnes désireuses d'établir certaines règles et conditions pour la répartition des valeurs, ainsi qu'un mécanisme permettant de garantir la mise en œuvre de cette répartition selon les règles et conditions établies. Ils se réunissaient, rédigeaient un document avec leurs données d'identification, les conditions, les valeurs impliquées, indiquaient une date et signaient. Ce contrat était également validé par une partie de confiance, comme un notaire. Ensuite, ces personnes s'épargnaient avec leur exemplaire papier de ce contrat et commençaient à effectuer des actions qui pouvaient ne pas correspondre à ce même contrat, c'est-à-dire qu'elles faisaient une chose, tandis que le document indiquait qu'elles devaient en faire une autre. Comment sortir de cette situation ? En fait, il fallait qu'un des participants du groupe prenne ce document, recueille des preuves, aille au tribunal et obtienne l'accord entre le contrat et les actions réelles. Il est souvent difficile d'obtenir une exécution juste de ce contrat, ce qui entraîne des conséquences fâcheuses.
Que peut-on dire sur les contrats intelligents ? Ils combinent la possibilité de rédiger les conditions du contrat et un mécanisme de strict respect de celles-ci. Si les conditions ont été définies et qu'une transaction ou demande correspondante a été signée, il est alors impossible de modifier les conditions ou d'influencer leur exécution après l'acceptation de cette demande ou transaction.
Il y a un ou plusieurs validateurs, ainsi qu'une base de données qui stocke tous les contrats intelligents soumis à exécution dans un ordre chronologique strict. Il est également important que cette base de données contienne toutes les conditions-déclencheurs pour l'exécution du contrat intelligent. De plus, elle doit prendre en compte la valeur elle-même, dont la répartition est décrite dans le contrat. Si cela concerne une certaine monnaie numérique, alors cette base de données doit en tenir compte.
Autrement dit, les validateurs de contrats intelligents doivent avoir accès à toutes les données sur lesquelles opère le contrat intelligent. Par exemple, une seule base de données doit être utilisée pour suivre simultanément les monnaies numériques, les soldes des utilisateurs, les transactions des utilisateurs et les horodatages. Dans ce cas, une condition dans le contrat intelligent pourrait être le solde d’un utilisateur dans une certaine monnaie, l'arrivée d'un certain moment ou la réalisation d'une certaine transaction, mais pas plus.
Définition du contrat intelligent
En effet, la terminologie elle-même a été inventée par le chercheur Nick Szabo et appliquée pour la première fois en 1994, et a été documentée en 1997 dans un article qui décrit l'idée même des contrats intelligents.
Les contrats intelligents impliquent qu'une certaine automatisation de la répartition de valeur est réalisée, pouvant dépendre uniquement des conditions préétablies. Dans sa version la plus simple, cela ressemble à un contrat avec des conditions strictement définies, signé par des parties spécifiques.
Les contrats intelligents visent à minimiser la confiance dans les tiers. Parfois, le centre de décision, dont tout dépend, est complètement éliminé. De plus, pour ces contrats, il est plus simple d'effectuer un audit. Cela résulte de certaines particularités de conception de ce système, mais la plupart du temps, nous comprenons le contrat intelligent comme un environnement décentralisé et la présence de fonctions permettant à quiconque d'analyser la base de données et de réaliser un audit complet de l'exécution des contrats. Cela garantit ainsi la protection contre les modifications des données rétroactivement, qui entraîneraient des changements dans l'exécution même du contrat. La numérisation de la plupart des processus lors de la création et du lancement d'un contrat intelligent simplifie souvent la technologie et le coût de leur mise en œuvre.
Un exemple simple - service d'escrow
Considérons un exemple très simple. Cela aidera à comprendre les capacités fonctionnelles des contrats intelligents et à mieux cerner les cas dans lesquels ils devraient être utilisés.
Cela peut également être réalisé en utilisant Bitcoin, bien qu'il soit encore difficile de qualifier Bitcoin de véritable plateforme pour les contrats intelligents. Donc, nous avons un acheteur et un magasin en ligne. L'acheteur souhaite acheter un moniteur dans ce magasin. Dans le cas le plus simple, l'acheteur traite et envoie le paiement, et le magasin en ligne l'accepte, le confirme, puis envoie le produit. Cependant, cette situation implique un besoin de grande confiance - l'acheteur doit faire confiance au magasin en ligne pour le montant total du moniteur. Comme le magasin en ligne peut avoir une faible réputation aux yeux de l'acheteur, il existe un risque que, pour quelque raison que ce soit, après avoir accepté le paiement, le magasin refuse le service et n'expédie pas le produit à l'acheteur. C'est pourquoi l'acheteur se demande (et le magasin en ligne se pose également cette question) ce qui peut être appliqué dans ce cas pour minimiser de tels risques et rendre ces transactions plus fiables.
Dans le cas de Bitcoin, il est possible de permettre à l'acheteur et au vendeur de choisir indépendamment un médiateur. Il y a beaucoup de personnes qui s'occupent de la résolution de problèmes. Nos participants peuvent choisir parmi une liste commune de médiateurs celui auquel ils font confiance. Ensemble, ils créent une adresse multisignature 2 sur 3, où il y a trois clés et deux signatures de n'importe quelles deux clés sont nécessaires pour dépenser les pièces de cette adresse. Une clé appartiendra à l'acheteur, la seconde au magasin en ligne, et la troisième au médiateur. Et à cette adresse multisignature, l'acheteur enverra le montant nécessaire pour le paiement du moniteur. Maintenant, quand le vendeur voit que l'argent est bloqué pendant un certain temps sur l'adresse multisignature, qui dépend de lui, il peut avec assurance envoyer le moniteur par la poste.
Ensuite, l'acheteur reçoit le colis, inspecte le produit et prend une décision concernant l'achat final. Il peut être totalement satisfait du service fourni et signer la transaction avec sa clé, transférant ainsi des pièces de l'adresse à multisignature au vendeur, ou il peut être mécontent. Dans ce dernier cas, il contacte le médiateur pour établir une transaction alternative qui répartira ces pièces différemment.
Supposons que le moniteur soit arrivé légèrement rayé et que le câble pour le connecter à l'ordinateur ne soit pas inclus, bien que le site internet de la boutique en ligne indiquait que le câble devait être inclus. L'acheteur rassemble alors les preuves nécessaires pour prouver au médiateur qu'il a été trompé dans cette situation : il prend des captures d'écran du site, photographie le reçu de la poste, prend une photo des rayures sur le moniteur et montre que le sceau a été brisé et que le câble a été retiré. De son côté, la boutique en ligne collecte ses propres preuves et les transmet au médiateur.
Le médiateur est intéressé à satisfaire à la fois le mécontentement de l'acheteur et les intérêts de la boutique en ligne (cela deviendra clair plus tard). Il établit une transaction dans laquelle les pièces de l'adresse à multisignature seront dépensées dans une certaine proportion entre l'acheteur, la boutique en ligne et le médiateur, car il prend une part en tant que récompense pour son travail. Supposons que 90 % du montant total aille au vendeur, 5 % au médiateur et 5 % en compensation pour l'acheteur. Cette transaction est signée par le médiateur avec sa clé, mais elle ne peut pas encore être appliquée, car elle nécessite deux signatures, et seulement une est actuellement présente. Il envoie cette transaction à la fois à l'acheteur et au vendeur. Si au moins l'un d'eux est satisfait de cette option de redistribution des pièces, la transaction sera co-signée et diffusée sur le réseau. Pour sa validation, il suffit qu'un des participants à la transaction soit d'accord avec l'option du médiateur.
Il est donc important de choisir un médiateur de manière à ce que les deux parties lui fassent confiance. Dans ce cas, il agira indépendamment des intérêts de l'un ou de l'autre et évaluera la situation de manière objective. Si le médiateur ne propose pas une option de répartition des pièces qui satisfait au moins un participant, alors, d'un commun accord, l'acheteur et le magasin en ligne peuvent transférer les pièces vers une nouvelle adresse multisignature, en apposant leurs deux signatures. La nouvelle adresse multisignature sera créée avec un autre médiateur, qui sera peut-être plus compétent dans ce domaine et fournira une meilleure option.
Exemple avec une résidence universitaire et un réfrigérateur
Examinons un exemple plus complexe, qui illustre plus clairement les capacités d'un contrat intelligent.
Supposons qu'il y ait trois gars qui viennent de s'installer dans une même chambre dans une résidence universitaire. Ils sont tous les trois intéressés à acheter un réfrigérateur pour leur chambre, qu'ils utiliseront ensemble. L'un d'eux s'est porté volontaire pour rassembler le montant nécessaire à l'achat du réfrigérateur et pour négocier avec le vendeur. Cependant, ils se connaissent relativement peu et la confiance entre eux n'est pas suffisante. Évidemment, deux d'entre eux prennent un risque en donnant de l'argent au troisième. De plus, ils doivent parvenir à un consensus sur le choix du vendeur.
Ils peuvent utiliser un service d'entiercement, c'est-à-dire choisir un médiateur qui contrôlera l'exécution de la transaction et réglera les éventuels litiges, s'ils se présentent. Alors, d'un commun accord, ils établissent un contrat intelligent et y spécifient certaines conditions.
La première condition stipule que, jusqu'à un certain moment, par exemple dans un délai d'une semaine, trois paiements d'adresses spécifiques d'un montant précis doivent être reçus sur le compte correspondant du smart contract. Si cela ne se produit pas, le smart contract cesse de s'exécuter et renvoie les jetons à tous les participants. En revanche, si la condition est remplie, les identifiants du vendeur et du médiateur sont définis, et il est également vérifié que tous les participants sont d'accord avec le choix du vendeur et du médiateur. Lorsque toutes les conditions sont remplies, les fonds seront transférés aux adresses indiquées. Une telle approche peut protéger les participants contre la fraude de toutes parts et élimine complètement la nécessité de faire confiance.
Cet exemple illustre le principe selon lequel cette possibilité de définir progressivement les paramètres pour l'exécution de chaque condition permet de créer des systèmes de n'importe quelle complexité et profondeur d'imbrication. De plus, il est possible de définir d'abord la première condition dans le smart contract, puis, seulement après sa réalisation, de définir les paramètres pour la condition suivante. Autrement dit, formellement, la condition est inscrite, tandis que les paramètres peuvent être définis durant son exécution.
Classification des smart contracts
Pour la classification, différents groupes de critères peuvent être appliqués. Cependant, à ce stade de l'évolution technologique, quatre de ces groupes sont pertinents.
Les smart contracts peuvent être distingués selon l'environnement d'exécution, qui peut être soit centralisé, soit décentralisé. En cas de décentralisation, nous avons une indépendance et une résilience bien plus grandes lors de l'exécution des smart contracts.
Ils peuvent également être distingués en fonction du processus de définition et d'exécution des conditions : ils peuvent être programmables de manière arbitraire, limités ou prédéfinis, c'est-à-dire strictement typés. Lorsque sur la plateforme des smart contracts, il n'existe que 4 smart contracts spécifiques, les paramètres peuvent être définis de manière arbitraire. Par conséquent, il est beaucoup plus simple de les définir : nous choisissons un contrat dans la liste et transmettons les paramètres.
En termes d'initiation, il existe des contrats intelligents automatisés, c'est-à-dire qu'ils s'exécutent d'eux-mêmes lorsque certaines conditions sont remplies, tandis qu'il y a des contrats où les conditions sont définies, mais la plateforme ne vérifie pas automatiquement leur exécution, et il faut les initier séparément.
De plus, les contrats intelligents diffèrent par leur niveau de confidentialité. Ils peuvent être entièrement publics, partiellement ou complètement confidentiels. Ce dernier signifie que les observateurs externes ne voient pas les conditions des contrats intelligents. Cependant, la question de la confidentialité est très vaste et il est préférable de l'examiner séparément de l'article actuel.
Nous allons maintenant examiner plus en détail les trois premiers critères pour clarifier le sujet en cours.
Contrats intelligents par environnement d'exécution
En fonction de l'environnement d'exécution, on distingue les plateformes de contrats intelligents centralisées et décentralisées. Dans le cas des contrats numériques centralisés, un seul service est utilisé, avec un seul validateurs, et il peut y avoir un service de sauvegarde et de récupération, également géré de manière centralisée. Il y a une base de données qui stocke toutes les informations nécessaires pour définir les conditions du contrat intelligent et distribuer la valeur considérée dans cette base de données. Ce type de service centralisé a un client qui définit les conditions par des requêtes spécifiques et utilise de tels contrats. Étant donné que la plateforme est centralisée, les mécanismes d'authentification peuvent être moins fiables que dans les cryptomonnaies.
Comme exemple, on peut prendre les fournisseurs de services mobiles (différents opérateurs mobiles). Supposons qu'un certain opérateur gère de manière centralisée le suivi du trafic sur ses serveurs, qui peut être transmis dans différents formats, par exemple : en tant qu'appels vocaux, envoi de SMS, trafic Internet mobile, et selon différents standards, tout en maintenant un suivi des fonds sur les soldes des utilisateurs. Par conséquent, le fournisseur de services mobiles peut établir des contrats pour le suivi des services fournis et leur paiement avec différentes conditions. Dans ce cas, il est facile de définir des conditions du type 'envoyer un SMS avec un certain code à un certain numéro et recevoir des conditions particulières pour la distribution de trafic'.
On peut aussi donner un autre exemple : les banques traditionnelles avec des fonctions avancées de banque en ligne et des contrats très simples, comme des paiements réguliers, la conversion automatique des paiements entrants, l'imputation automatique d'un intérêt sur un compte spécifié, etc.
S'il s'agit de contrats intelligents dans un environnement d'exécution décentralisé, alors nous avons un groupe de validateurs. Idéalement, n'importe qui peut devenir valideur. Grâce au protocole de synchronisation de base de données et à l'atteinte d'un consensus, nous avons une base de données commune qui stocke désormais toutes les transactions avec des contrats strictement décrits, et non des requêtes conditionnelles dont les formats changent souvent et pour lesquelles il n'existe pas de spécification ouverte. Ici, les transactions contiendront des instructions pour exécuter le contrat selon une spécification stricte. Cette spécification est ouverte et, par conséquent, les utilisateurs de la plateforme peuvent auditer et valider les contrats intelligents. Ici, nous voyons que les plateformes décentralisées surpassent les centrales en termes d'indépendance et de résilience, mais leur conception et leur maintenance sont beaucoup plus complexes.
Contrats intelligents par méthode de définition et d'exécution des conditions
Examinons maintenant plus en détail comment les contrats intelligents peuvent différer par la manière de définir et d'exécuter les conditions. Ici, nous porterons notre attention sur les contrats intelligents qui sont programmés de manière arbitraire et qui sont Turing-complets. Un contrat intelligent Turing-complet permet de définir pratiquement n'importe quel algorithme comme condition d'exécution du contrat : d'écrire des boucles, des fonctions de calcul de probabilités, et ainsi de suite — jusqu'à ses propres algorithmes de signature électronique. Dans ce cas, on parle réellement d'une écriture arbitraire de la logique.
On distingue également des contrats intelligents arbitraires, mais non Turing-complets. On peut y inclure Bitcoin et Litecoin avec leur script. Cela signifie qu'il est possible d'utiliser uniquement certaines opérations dans un ordre arbitraire, mais il n'est pas possible d'écrire des boucles ou des algorithmes personnalisés.
De plus, il existe des plateformes de contrats intelligents qui mettent en œuvre des contrats intelligents préétablis. On peut citer Bitshares et Steemit. Bitshares dispose d'une gamme de contrats intelligents pour le commerce, la gestion des comptes, ainsi que la gestion de la plateforme et de ses paramètres. Steemit est une plateforme similaire, mais elle est davantage axée sur la gestion de blogs, c'est-à-dire qu'elle stocke et traite le contenu de manière décentralisée.
Parmi les contrats complets en Turing, on peut inclure la plateforme Ethereum et RootStock, qui est encore en cours de développement. Nous allons donc approfondir notre exploration de la plateforme de contrats intelligents Ethereum.
Contrats intelligents par méthode d'initialisation
Concernant la méthode d'initialisation, les contrats intelligents peuvent être classés en au moins deux groupes : automatisés et manuels (non automatisés). Les contrats automatisés fonctionnent de telle manière qu'avec tous les paramètres connus et les conditions remplies, le contrat intelligent s'exécute intégralement de manière automatique, c'est-à-dire qu'il ne nécessite pas l'envoi de transactions supplémentaires et le paiement de frais supplémentaires à chaque fois pour l'exécution suivante. La plateforme possède toutes les données nécessaires pour déterminer comment le contrat intelligent sera complété. La logique n'y est pas aléatoire, mais prédéfinie, ce qui le rend prévisible. Autrement dit, il est possible d'évaluer à l'avance la complexité de l'exécution du contrat intelligent, d'utiliser un frais constant pour celui-ci et tous les processus associés se déroulent de manière plus efficace.
Pour les contrats intelligents programmables de manière arbitraire, l'exécution n'est pas automatisée. Pour initier un tel contrat intelligent, il est nécessaire de créer une nouvelle transaction à chaque étape, qui déclenchera la prochaine étape d'exécution ou la méthode suivante du contrat intelligent, de payer les frais correspondants et d'attendre la confirmation de la transaction. L'exécution peut très bien se terminer avec succès ou échouer, car le code du contrat intelligent est arbitraire et divers imprévus tels que des boucles infinies, le manque de certains paramètres et arguments, des exceptions non traitées, etc., peuvent survenir.
Comptes dans Ethereum
Types de comptes Ethereum
Examinons les types de comptes sur la plateforme Ethereum. Il n'existe que deux types de comptes, et il n'y a pas d'autres options. Le premier type est appelé compte utilisateur, le second — compte contrat. Voyons en quoi ils diffèrent.
Le compte utilisateur est géré uniquement par une clé personnelle de signature électronique. Le propriétaire du compte génère sa paire de clés pour la signature électronique selon l'algorithme ECDSA (Elliptic Curve Digital Signature Algorithm). L'état de ce compte peut uniquement être modifié par des transactions signées par cette clé.
Pour le compte de contrat intelligent, une logique distincte est prévue. Il ne peut être géré que par un code programmé à l'avance, qui définit entièrement le comportement du contrat intelligent : comment il disposera de ses pièces dans certaines circonstances, à l'initiative de quel utilisateur, et sous quelles conditions supplémentaires ces pièces seront distribuées. Si certains aspects ne sont pas prévus par les développeurs dans le code, des problèmes peuvent survenir. Par exemple, un contrat intelligent peut atteindre un état particulier où il n'accepte l'initiation d'aucune exécution de la part des utilisateurs. Dans ce cas, les pièces seront effectivement gelées, car le contrat intelligent ne prévoit pas de sortie de cet état.
Comment les comptes sont créés dans Ethereum
Dans le cas du compte utilisateur, le propriétaire génère lui-même une paire de clés via ECDSA. Il est important de noter qu'Ethereum utilise exactement le même algorithme et la même courbe elliptique pour la signature électronique que Bitcoin, mais l'adresse est calculée de manière légèrement différente. Ici, le résultat du double hachage, comme dans Bitcoin, n'est plus utilisé, mais un hachage simple est prévu avec la fonction Keccak sur 256 bits. Les bits de poids bas sont coupés, soit les 160 bits de poids bas de la sortie de la fonction de hachage. Au final, nous obtenons une adresse dans Ethereum. En fait, elle occupe 20 octets.
Il convient de noter que l'identifiant du compte dans Ethereum est encodé en hexadécimal sans utiliser de somme de contrôle, contrairement à Bitcoin et à de nombreux autres systèmes, où l'adresse est codée en base 58 avec l'ajout d'une somme de contrôle. Cela signifie qu'il faut faire preuve de prudence lors de l'utilisation des identifiants de comptes dans Ethereum : même une seule erreur dans l'identifiant entraînera inévitablement la perte de pièces.
Il y a une caractéristique importante, qui est que le compte de l'utilisateur sur le niveau de la base de données globale est créé au moment où il reçoit son premier paiement entrant.
En ce qui concerne la création d'un compte de contrat intelligent, une approche complètement différente est appliquée. Au départ, l'un des utilisateurs écrit le code source du contrat intelligent, après quoi le code est passé par un compilateur spécifique à la plateforme Ethereum, générant du bytecode pour sa propre machine virtuelle Ethereum. Le bytecode obtenu est placé dans un champ spécial de la transaction. Elle est signée au nom du compte de l'initiateur. Ensuite, cette transaction est diffusée sur le réseau et déploie le code du contrat intelligent. Les frais de la transaction et, par conséquent, ceux de l'exécution du contrat, sont prélevés sur le solde du compte de l'initiateur.
Chaque contrat intelligent contient obligatoirement son propre constructeur (de ce contrat). Il peut être vide, ou avoir un contenu. Une fois que le constructeur est exécuté, un identifiant de compte de contrat intelligent est créé, ce qui permet d'envoyer des pièces, d'appeler certaines méthodes du contrat intelligent, etc.
La structure de la transaction Ethereum
Pour être plus clair, nous allons examiner la structure de la transaction Ethereum et un exemple de code de contrat intelligent.
Une transaction Ethereum se compose de plusieurs champs. Le premier d'entre eux, le nonce, est un certain numéro séquentiel de la transaction par rapport au compte qui l'initie et en est l'auteur. Ceci est nécessaire pour différencier les doublons de transactions, afin d'éviter le cas où la même transaction est acceptée deux fois. Grâce à l'utilisation de l'identifiant, chaque transaction a une valeur de hachage unique.
Vient ensuite un champ tel que prix du gazVoici le prix auquel la devise de base Ethereum est convertie en gas, qui est utilisé pour payer l'exécution des contrats intelligents et pour l'allocation des ressources de la machine virtuelle. Qu'est-ce que cela signifie ?
Dans Bitcoin, les frais sont payés directement avec la devise de base — le bitcoin lui-même. Cela est rendu possible grâce à un mécanisme simple de calcul : nous payons strictement en fonction du volume de données contenu dans la transaction. Dans Ethereum, la situation est plus complexe car il est difficile de se baser uniquement sur le volume de données de la transaction. Ici, la transaction peut également contenir du code qui sera exécuté sur la machine virtuelle, et chaque opération de la machine virtuelle peut avoir une complexité différente. Il existe également des opérations qui allouent de la mémoire pour des variables. Elles auront leur propre complexité, qui déterminera le paiement pour chaque opération.
Le coût de chaque opération en équivalent gas sera constant. Il a été introduit spécifiquement pour déterminer le coût constant de chaque opération. En fonction de la charge sur le réseau, le gas price changera, c'est-à-dire le coefficient selon lequel la devise de base sera convertie en cette unité auxiliaire pour le paiement des frais.
Il y a aussi une autre caractéristique des transactions dans Ethereum : le bytecode qu'elle contient pour l'exécution dans la machine virtuelle sera exécuté jusqu'à ce qu'il se termine par un certain résultat (succès ou échec) ou jusqu'à ce qu'un certain montant de pièces alloué pour le paiement des frais soit épuisé. C'est justement pour éviter une situation où tous les fonds du compte de l'expéditeur sont dépensés pour le frais en cas d'erreur (par exemple, si une boucle infinie se déclenche dans la machine virtuelle) qu'il existe le champ suivant — start gas (souvent appelé gas limit) — il définit le montant maximum de pièces que l'expéditeur est prêt à dépenser pour effectuer une transaction spécifique.
Le champ suivant est appelé destination address. Ici, l'adresse du destinataire des pièces ou l'adresse d'un contrat intelligent spécifique dont les méthodes seront appelées est inscrite. Après cela, il y a le champ value, où le montant des pièces à envoyer à l'adresse de destination est inscrit.
Ensuite, il y a un champ intéressant appelé data, où une structure entière est intégrée. Ce n'est pas un champ distinct, mais une structure complète, dans laquelle le code pour la machine virtuelle est défini. On peut y placer des données arbitraires — des règles spécifiques existent à cet effet.
Et le dernier champ s'appelle signature. Il contient à la fois la signature électronique de l'auteur de cette transaction et la clé publique qui sera utilisée pour vérifier cette signature. À partir de la clé publique, on peut obtenir l'identifiant du compte de l'expéditeur de cette transaction, ce qui permet d'identifier de manière unique le compte de l'expéditeur dans le système. Nous avons déterminé l'essentiel concernant la structure de la transaction.
Exemple de code de contrat intelligent en Solidity
Examinons maintenant plus en détail le contrat intelligent le plus simple à titre d'exemple.
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}Le code source simplifié ci-dessus peut détenir les pièces des utilisateurs et les rendre sur demande.
Ainsi, il existe un contrat intelligent Bank, qui remplit les fonctions suivantes : il accumule des pièces sur son solde, c'est-à-dire qu'après la confirmation de la transaction et le déploiement de ce contrat intelligent, un nouveau compte est créé, qui peut contenir des pièces dans son solde ; il mémorise les utilisateurs et la répartition des pièces entre eux ; il possède plusieurs méthodes de gestion des soldes, offrant ainsi la possibilité de recharger, de retirer et de vérifier le solde de l'utilisateur.
Passons en revue chaque ligne du code source. Dans ce contrat, il y a des champs constants. L'un d'eux, de type address, s'appelle owner. Ici, le contrat mémorise l'adresse de l'utilisateur qui a créé ce contrat intelligent. Ensuite, il y a une structure dynamique qui conserve les correspondances entre les adresses des utilisateurs et leurs soldes.
Après cela, il y a la méthode Bank — c'est le même nom que le contrat. Par conséquent, c'est son constructeur. Ici, la variable owner est assignée à l'adresse de celui qui a déployé ce contrat intelligent sur le réseau. C'est la seule opération effectuée dans ce constructeur. Autrement dit, msg, dans ce cas, ce sont précisément les données qui ont été transmises à la machine virtuelle avec la transaction contenant tout le code de ce contrat. Par conséquent, msg.sender est l'auteur de cette transaction qui déploie ce code. Il sera le propriétaire du contrat intelligent.
La méthode deposit permet de transférer un certain nombre de pièces sur le compte d'un contrat par une transaction. Dans ce cas, le contrat intelligent, en recevant ces pièces, les conserve dans son solde, mais enregistre dans la structure balances qui a été l'expéditeur de ces pièces, afin de savoir à qui elles appartiennent.
La méthode suivante s'appelle withdraw et elle prend un paramètre : le montant de pièces que quelqu'un souhaite retirer de cette banque. Il y a une vérification pour savoir si le solde de l'utilisateur qui appelle cette méthode est suffisant pour les envoyer. Si c'est le cas, le contrat intelligent renvoie cette quantité de pièces à l'appelant.
Ensuite, il y a une méthode pour vérifier le solde actuel de l'utilisateur. Celui qui appelle cette méthode sera utilisé pour obtenir ce solde dans le contrat intelligent. Il convient de noter que le modificateur de cette méthode est view. Cela signifie que la méthode ne modifie pas les variables de sa classe et qu'elle est en réalité uniquement une méthode de lecture. Une transaction distincte n'est pas créée pour appeler cette méthode, aucuns frais ne sont payés et tous les calculs sont effectués localement, après quoi l'utilisateur reçoit le résultat.
La méthode kill est destinée à détruire l'état du contrat intelligent. Une vérification supplémentaire est intégrée pour déterminer si l'appelant de cette méthode est le propriétaire du contrat. Si oui, le contrat se détruit de lui-même, et la fonction de destruction prend un paramètre : l'identifiant du compte sur lequel le contrat enverra toutes les pièces restantes sur son solde. Dans ce cas, les pièces restantes iront automatiquement à l'adresse du propriétaire du contrat.
Comment fonctionne un nœud complet du réseau Ethereum ?
Voyons schématiquement comment ces contrats intelligents sont exécutés sur la plateforme Ethereum et comment fonctionne un nœud complet du réseau.
Un nœud complet du réseau Ethereum doit au moins avoir quatre modules.
Le premier, comme pour tout protocole décentralisé, est le module de réseautage P2P — le module de connexion réseau et de communication avec d'autres nœuds, où s'effectue l'échange de blocs, de transactions, d'informations sur d'autres nœuds. C'est un composant traditionnel pour toutes les cryptomonnaies décentralisées.
Ensuite, nous avons un module de stockage des données de la blockchain, de traitement, de sélection de la branche principale, d'ajout de blocs, de dissociation de blocs, de vérification de ces blocs, etc.
Le troisième module s'appelle EVM (machine virtuelle Ethereum) — c'est cela machine virtuelle, qui accepte le bytecode d'une transaction Ethereum. Ce module prend l'état actuel d'un compte particulier et exécute les modifications de son état basées sur le bytecode reçu. La version de la machine virtuelle sur chaque nœud du réseau doit être la même. Les calculs se font sur chaque nœud Ethereum de manière absolument identique, mais ils se produisent de manière asynchrone : quelqu'un vérifie et accepte cette transaction plus tôt, c'est-à-dire exécute tout le code qu'elle contient, et quelqu'un plus tard. Ainsi, lors de la création d'une transaction, elle se propage dans le réseau, les nœuds l'acceptent et au moment de la vérification, tout comme dans Bitcoin, où le Bitcoin Script s'exécute, ici le bytecode de la machine virtuelle est exécuté.
Une transaction est considérée comme vérifiée si tout le code qu'elle contient a été exécuté, qu'un nouvel état d'un compte particulier a été généré et conservé jusqu'à ce qu'il soit clair que cette transaction a été appliquée ou non. Si la transaction est appliquée, alors cet état est considéré non seulement comme exécuté, mais aussi comme actuel. Il existe une base de données qui stocke l'état de chaque compte pour chaque nœud du réseau. Étant donné que tous les calculs se déroulent de la même manière et que l'état de la blockchain est identique, la base de données contenant les états de tous les comptes sera également identique pour chaque nœud.
Mythes et limitations des contrats intelligents
En ce qui concerne les limitations qui existent pour des plateformes de contrats intelligents similaires à Ethereum, on peut citer les suivantes :
- exécution de code;
- allocation de mémoire;
- données de la blockchain;
- effectuer des paiements;
- créer un nouveau contrat;
- appeler d'autres contrats.
Examinons les limitations imposées à la machine virtuelle et, par conséquent, dissipons quelques mythes sur les contrats intelligents. Sur une machine virtuelle, qui peut être non seulement sur Ethereum mais aussi sur des plateformes similaires, il est possible d'exécuter de véritables opérations logiques arbitraires, c'est-à-dire d'écrire du code qui sera exécuté là-bas, et de réserver de la mémoire supplémentaire. Cependant, des frais sont appliqués séparément pour chaque opération et pour chaque unité de mémoire supplémentaire allouée.
Ensuite, la machine virtuelle peut lire des données à partir de la base de données de la blockchain, afin d'utiliser ces données comme déclencheurs pour exécuter telle ou telle logique des contrats intelligents. La machine virtuelle peut créer et envoyer des transactions, elle peut créer de nouveaux contrats et appeler les méthodes d'autres contrats intelligents déjà publiés en ligne : ceux qui existent, sont accessibles, etc.
Le mythe le plus répandu est que les contrats intelligents Ethereum peuvent utiliser des informations de n'importe quelle ressource Internet dans leurs conditions. La vérité est que la machine virtuelle ne peut pas envoyer de requête réseau à une ressource d'information externe sur Internet, c'est-à-dire qu'il n'est pas possible d'écrire un tel contrat intelligent qui répartirait la valeur entre les utilisateurs en fonction, par exemple, de la météo extérieure, du gagnant d'un championnat, ou d'un autre événement survenu dans le monde extérieur, car il n'y a tout simplement pas d'informations sur ces événements dans la base de données de la plateforme elle-même. Donc, rien à ce sujet dans la blockchain. S'il n'y apparaît pas, la machine virtuelle ne peut pas utiliser ces données comme déclencheurs.
Inconvénients d'Ethereum
Énumérons les principaux inconvénients. Le premier inconvénient est qu'il existe certaines difficultés lors de la conception, du développement et des tests des contrats intelligents sur Ethereum (pour écrire des contrats intelligents sur Ethereum, on utilise le langage Solidity). En effet, l'expérience montre qu'un très grand pourcentage des erreurs est dû au facteur humain. Cela est également vrai pour les contrats intelligents Ethereum déjà écrits, qui présentent une complexité moyenne ou supérieure. Alors que pour les contrats intelligents simples, la probabilité d'erreur est faible, dans les contrats intelligents complexes, on rencontre très souvent des erreurs qui entraînent le vol de fonds, leur gel, ou la destruction imprévue des contrats intelligents, etc. De nombreux cas de ce type sont déjà connus.
Le deuxième inconvénient est que la machine virtuelle elle-même n'est pas parfaite, car elle est également écrite par des humains. Elle peut exécuter des commandes arbitraires et c'est là que réside la vulnérabilité : il est possible de configurer certaines commandes d'une manière qui entraînera des conséquences imprévues. Il s'agit d'un domaine très complexe, mais plusieurs études montrent déjà qu'il existe des vulnérabilités dans la version actuelle du réseau Ethereum qui peuvent entraîner un défaut de fonctionnement de nombreux contrats intelligents.
Une autre grande difficulté, que l'on peut considérer comme un inconvénient, est qu'il est possible, d'une manière pratique ou technique, de déterminer qu'en compilant le bytecode d'un contrat qui s'exécutera sur la machine virtuelle, il est possible de définir un certain ordre spécifique des opérations. Lors de l'exécution conjointement, ces opérations chargeront très fortement la machine virtuelle et la ralentiront de manière disproportionnée par rapport à la commission qui a été payée pour l'exécution de ces opérations.
Il y a eu un pas précédent dans l'évolution d'Ethereum, lorsque de nombreux développeurs ayant une connaissance approfondie du fonctionnement de la machine virtuelle découvraient de telles vulnérabilités. En réalité, les transactions avaient des frais très faibles, mais elles ralentissaient considérablement le fonctionnement de l'ensemble du réseau. Ces problèmes sont très difficiles à résoudre, car il faut, d'une part, les déterminer, d'autre part, ajuster le prix pour l'exécution de ces opérations, et enfin, procéder à un hard fork, ce qui signifie mettre à jour tous les nœuds du réseau vers une nouvelle version du logiciel, puis activer simultanément ces changements.
Concernant Ethereum, de nombreuses études ont été menées, et une grande expérience pratique a été acquise : tant positive que négative, mais néanmoins, il reste des complexités et des vulnérabilités avec lesquelles il va falloir encore lutter.
Ainsi, la partie thématique de l'article est terminée, passons aux questions qui se posent assez souvent.
Questions fréquentes
— Si toutes les parties d'un contrat intelligent en cours souhaitent modifier les conditions, peuvent-elles annuler ce contrat intelligent au moyen de signatures multiples, puis créer un nouveau contrat intelligent avec des conditions mises à jour ?
La réponse ici sera double. Pourquoi ? Parce que d'une part, le contrat intelligent est fixé une fois pour toutes et il ne suppose aucune modification, mais d'autre part, il peut avoir une logique prédéfinie qui prévoit des modifications totales ou partielles de certaines conditions. Donc, si vous souhaitez modifier quelque chose dans votre contrat intelligent, vous devez au préalable définir les conditions selon lesquelles vous pouvez actualiser ces conditions. Par conséquent, c'est seulement de cette manière prévoyante que vous pouvez organiser la mise à jour du contrat. Mais même ici, il est possible de rencontrer des difficultés : faire une erreur et obtenir une vulnérabilité correspondante. Ainsi, de telles choses doivent être conçues et testées avec beaucoup de minutie.
— Que se passe-t-il si le médiateur collude avec l'une des parties prenantes : l'escrow ou le contrat intelligent ? Le médiateur est-il obligatoire dans un contrat intelligent ?
Un médiateur n'est pas obligatoire dans un smart contract. Il peut ne pas y avoir de médiateur. Si, dans le cas d'un escrow, le médiateur conspirait avec une des parties, alors oui, ce schéma perdrait toute sa valeur. C'est pourquoi les médiateurs sont choisis de manière à ce que toutes les parties impliquées dans ce processus leur fassent confiance simultanément. Par conséquent, vous ne transférerez simplement pas de pièces à une adresse multisignature avec un médiateur en qui vous n'avez pas confiance.
— Est-il possible de transférer plusieurs tokens différents d'une seule transaction Ethereum de mon adresse vers différentes adresses cibles, par exemple vers les adresses d'échange où ces tokens sont négociés ?
C'est une bonne question et elle concerne le modèle des transactions Ethereum et ses différences par rapport au modèle Bitcoin. Et cette différence est radicale. Dans le modèle de transaction Ethereum, vous transférez simplement des pièces, elles passent d'une adresse à une autre, sans reste, juste le montant spécifique que vous avez indiqué. En d'autres termes, ce n'est pas un modèle de sorties non dépensées (UTXO), mais plutôt un modèle de comptes et de soldes correspondants. Théoriquement, il est possible d'envoyer plusieurs tokens différents en une seule transaction si l'on écrit un smart contract astucieux, mais il faudra tout de même effectuer de nombreuses transactions, créer un contrat, puis lui transférer des tokens et des pièces, avant d'appeler la méthode correspondante. Cela demande des efforts et du temps, par conséquent, en pratique, cela ne fonctionne pas de cette manière et tous les paiements en Ethereum sont effectués par des transactions distinctes.
— L'un des mythes concernant la plateforme Ethereum est qu'il est impossible de décrire des conditions qui dépendent de données d'une ressource Internet externe, que faire alors ?
La solution réside dans le fait que le smart contract peut prévoir un ou plusieurs oracles de confiance, qui collectent des données sur l'état des choses dans le monde extérieur et les transmettent aux smart contracts via des méthodes spéciales. Le contrat lui-même considère comme vraies les données qu'il a reçues de sources de confiance. Pour plus de fiabilité, on choisit simplement un groupe plus large d'oracles et on minimise le risque de collusion. Le contrat lui-même peut ignorer les données des oracles qui contredisent la majorité.
Ce sujet est abordé dans l'une des leçons du cours en ligne sur la Blockchain — “”.
Source : habr.com
