Dans cet article, nous aborderons la notion de contrats intelligents, leurs types, les différentes plateformes de contrats intelligents et leurs fonctionnalités, ainsi que leur structure et leurs avantages. Cet article sera très utile aux lecteurs qui ne sont pas encore familiarisés avec le sujet des contrats intelligents, mais souhaitent approfondir leur compréhension.
Contrat régulier vs. contrat intelligent
Avant d’entrer dans les détails, examinons un exemple de la différence entre un contrat ordinaire, écrit sur papier, et un contrat intelligent, représenté numériquement.
Comment fonctionnait-on avant les contrats intelligents ? Imaginez un groupe de personnes souhaitant établir des règles et des conditions pour la distribution de valeurs, ainsi qu'un mécanisme garantissant que cette distribution soit effectuée conformément à ces règles et conditions. Ils se réunissent ensuite, rédigent un document sur lequel ils notent leurs données d'identification, les conditions et les valeurs concernées, apposent la date et signent. Ce contrat est également certifié par une personne de confiance, par exemple un notaire. Ensuite, chacun se sépare avec sa copie papier du contrat et commence à effectuer des actions qui peuvent ne pas correspondre au contrat lui-même : ils font une chose, mais le document certifie qu'ils doivent en faire une autre. Comment sortir de cette situation ? En fait, l'un des membres du groupe doit prendre ce document, rassembler des preuves, le porter devant les tribunaux et obtenir la conformité du contrat avec les actes réels. Bien souvent, il est difficile d'obtenir une exécution équitable de ce contrat, ce qui entraîne des conséquences fâcheuses.
Que dire des contrats intelligents ? Ils combinent la possibilité de rédiger des clauses contractuelles et un mécanisme permettant leur mise en œuvre rigoureuse. Une fois les clauses définies et la transaction ou la demande correspondante signée, il n'est plus possible, après acceptation de cette demande ou de cette transaction, de modifier les clauses ni d'influencer leur mise en œuvre.
Il existe un validateur ou un réseau complet, ainsi qu'une base de données stockant 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 de déclenchement de l'exécution du contrat intelligent. De plus, elle doit prendre en compte la valeur dont la distribution est décrite dans le contrat. S'il s'agit d'une monnaie numérique, cette base de données doit la prendre en compte.
En d'autres termes, les validateurs de contrats intelligents doivent avoir accès à toutes les données sur lesquelles le contrat fonctionne. Par exemple, une base de données doit être utilisée pour enregistrer simultanément les monnaies numériques, les soldes et les transactions des utilisateurs, ainsi que les horodatages. Ainsi, dans un contrat intelligent, une condition peut être le solde d'un utilisateur dans une certaine monnaie, l'arrivée à une certaine heure ou la réalisation d'une certaine transaction, mais rien de plus.
Définition d'un contrat intelligent
En fait, la terminologie elle-même a été inventée par le chercheur Nick Szabo et utilisé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 de contrats intelligents.
Les contrats intelligents impliquent une certaine automatisation de la distribution de la valeur, qui peut dépendre uniquement de conditions prédéfinies. Dans sa forme la plus simple, cela ressemble à un contrat aux conditions strictement définies, signé par certaines parties.
Les contrats intelligents sont conçus pour minimiser la confiance envers les tiers. Parfois, le centre de décision, dont tout dépend, est totalement exclu. De plus, il est plus facile d'auditer ces contrats. Cela est dû à certaines caractéristiques de conception d'un tel système, mais le plus souvent, on considère un contrat intelligent comme un environnement décentralisé doté de fonctions permettant à quiconque d'analyser la base de données et de réaliser un audit complet de l'exécution du contrat. Cela garantit une protection contre les modifications rétroactives des données qui pourraient modifier l'exécution du contrat lui-même. La numérisation de la plupart des processus de création et de lancement d'un contrat intelligent simplifie souvent la technologie et le coût de sa mise en œuvre.
Un exemple simple est le service d'entiercement
Prenons un exemple très simple. Il nous aidera à mieux comprendre le fonctionnement des contrats intelligents et à mieux comprendre quand les utiliser.
Cette solution peut également être mise en œuvre avec Bitcoin, bien que Bitcoin soit encore difficile à qualifier de plateforme complète pour les contrats intelligents. Prenons l'exemple d'un acheteur et d'une boutique en ligne. L'acheteur souhaite acheter un moniteur. Dans le cas le plus simple, l'acheteur effectue et envoie un paiement, la boutique en ligne l'accepte, le confirme, puis expédie la marchandise. Cependant, dans ce cas, une grande confiance est requise : l'acheteur doit faire confiance à la boutique en ligne pour le coût total du moniteur. La boutique en ligne pouvant avoir une mauvaise réputation auprès de l'acheteur, il existe un risque que, pour une raison quelconque, après avoir accepté le paiement, elle refuse le service et ne lui envoie pas la marchandise. Par conséquent, l'acheteur se demande (et, par conséquent, la boutique en ligne se pose cette question) comment minimiser ces risques et fiabiliser les transactions.
Dans le cas du Bitcoin, nous offrons la possibilité à l'acheteur et au vendeur de choisir indépendamment un médiateur. De nombreux acteurs sont amenés à gérer les litiges. Nos participants peuvent choisir, parmi une liste commune de médiateurs, celui auquel ils accordent leur confiance. Ensemble, ils créent une adresse multisignature 2/3, contenant trois clés et deux signatures requises pour utiliser les cryptomonnaies depuis cette adresse. Une clé appartient à l'acheteur, la seconde à la boutique en ligne et la troisième au médiateur. L'acheteur envoie alors le montant nécessaire au paiement du moniteur à cette adresse multisignature. Désormais, lorsque le vendeur constate que l'argent est bloqué temporairement à l'adresse multisignature dont il dépend, il peut envoyer le moniteur en toute sécurité par courrier.
L'acheteur reçoit ensuite le colis, inspecte la marchandise et prend sa décision finale d'achat. Il peut être entièrement satisfait du service fourni et signer la transaction avec sa clé, transférant les pièces de l'adresse multisignature au vendeur, ou être insatisfait d'un point. Dans le second cas, il contacte le médiateur pour établir une transaction alternative qui répartira ces pièces différemment.
Supposons que l'écran soit arrivé légèrement rayé et qu'il n'y ait pas de câble de connexion à l'ordinateur dans le kit, alors que le site web 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é : il prend des captures d'écran du site web, une photo du reçu de la poste, une photo des rayures sur l'écran et montre que l'opercule a été arraché et que le câble a été arraché. La boutique en ligne, à son tour, recueille ses preuves et les transmet au médiateur.
Le médiateur souhaite satisfaire à la fois l'indignation du client et les intérêts de la boutique en ligne (on comprendra pourquoi plus tard). Il crée une transaction dans laquelle les jetons de l'adresse multisignature seront distribués proportionnellement entre le client, la boutique en ligne et le médiateur, puisqu'il en prend une part en guise de récompense pour son travail. Supposons que 90 % du montant total reviennent au vendeur, 5 % au médiateur et 5 % à l'acheteur. Le médiateur signe cette transaction avec sa clé, mais elle ne peut pas encore être appliquée, car elle nécessite deux signatures, dont une seule est valable. Il envoie cette transaction à l'acheteur et au vendeur. Si au moins l'un d'eux est satisfait de cette option de redistribution des jetons, la transaction est re-signée et distribuée au réseau. Pour sa validation, il suffit qu'un des participants à la transaction accepte l'option du médiateur.
Il est important de choisir un médiateur dès le départ afin que les deux parties lui fassent confiance. Dans ce cas, il agira indépendamment des intérêts de l'une ou l'autre et évaluera la situation objectivement. Si le médiateur ne propose pas d'option de distribution de pièces satisfaisant au moins une partie, l'acheteur et la boutique en ligne peuvent, après accord, transférer les pièces vers une nouvelle adresse multisignature, en y apposant leurs deux signatures. Cette nouvelle adresse multisignature sera créée avec un autre médiateur, plus compétent en la matière et proposant une meilleure solution.
Exemple avec un dortoir et un réfrigérateur
Examinons un exemple plus complexe qui montre plus clairement les capacités d’un contrat intelligent.
Imaginons trois jeunes gens qui viennent d'emménager dans une chambre universitaire. Ils souhaitent acheter un réfrigérateur pour leur chambre, qu'ils utiliseront ensemble. L'un d'eux s'est porté volontaire pour réunir les fonds nécessaires à l'achat du réfrigérateur et négocier avec le vendeur. Cependant, ils ne se connaissent que depuis peu et la confiance entre eux est fragile. Il est évident que deux d'entre eux prennent un risque en donnant de l'argent au troisième. De plus, ils doivent se mettre d'accord sur le vendeur.
Ils peuvent recourir au service d'entiercement, c'est-à-dire choisir un médiateur qui supervisera l'exécution de la transaction et réglera les éventuels litiges. Après accord, ils rédigent un contrat intelligent et y précisent certaines conditions.
La première condition est qu'avant un certain délai, par exemple dans un délai d'une semaine, trois paiements d'un montant donné provenant de certaines adresses doivent être reçus sur le compte du contrat intelligent correspondant. Dans le cas contraire, le contrat intelligent s'arrête et restitue les cryptomonnaies à tous les participants. Si la condition est remplie, les valeurs des identifiants du vendeur et du médiateur sont définies, et la condition d'accord de tous les participants avec le choix du vendeur et du médiateur est vérifiée. Lorsque toutes les conditions sont remplies, les fonds sont transférés aux adresses spécifiées. Cette approche protège les participants contre toute fraude et élimine généralement le besoin de confiance.
Dans cet exemple, nous voyons le principe même selon lequel la possibilité de paramétrer progressivement la réalisation de chaque condition permet de créer des systèmes de toute complexité et de niveaux imbriqués. De plus, la première condition peut être définie dans le contrat intelligent, et ce n'est qu'après sa réalisation que les paramètres de la condition suivante peuvent être définis. Autrement dit, la condition est formellement prescrite et ses paramètres peuvent être définis pendant son exécution.
Classification des contrats intelligents
Pour la classification, différents groupes de critères peuvent être définis. Cependant, à l'heure actuelle du développement technologique, quatre d'entre eux sont pertinents.
Les contrats intelligents se distinguent par leur environnement d'exécution, qui peut être centralisé ou décentralisé. Dans le cas de la décentralisation, l'indépendance et la tolérance aux pannes sont bien supérieures lors de l'exécution des contrats intelligents.
On les distingue également par le processus de définition et de réalisation des conditions : ils peuvent être arbitrairement programmables, limités ou prédéfinis, c'est-à-dire strictement typés. Lorsqu'il n'y a que quatre contrats intelligents spécifiques sur la plateforme, leurs paramètres peuvent être définis arbitrairement. Leur définition est donc beaucoup plus simple : il suffit de sélectionner un contrat dans la liste et de lui transmettre les paramètres.
Selon la méthode d'initiation, il existe des contrats intelligents automatisés, c'est-à-dire que lorsque certaines conditions se produisent, ils s'exécutent automatiquement, et il existe des contrats dans lesquels les conditions sont définies, mais la plateforme ne vérifie pas automatiquement leur réalisation ; pour cela, ils doivent être initiés séparément.
De plus, les contrats intelligents varient en termes de confidentialité. Ils peuvent être entièrement ouverts, partiellement ou totalement confidentiels. Dans ce dernier cas, les observateurs tiers ne peuvent pas consulter leurs termes. Cependant, le sujet de la confidentialité est très vaste et il est préférable de l'aborder séparément du présent article.
Ci-dessous, nous développerons les trois premiers critères pour apporter plus de clarté dans la compréhension du sujet actuel.
Contrats intelligents par environnement d'exécution
Selon l'environnement d'exécution, il existe des 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 validateur et éventuellement un service de sauvegarde et de récupération, lui aussi géré de manière centralisée. Une base de données stocke toutes les informations nécessaires à la définition des termes du contrat intelligent et à la distribution de la valeur prise en compte dans cette base de données. Un tel service centralisé dispose d'un client qui définit les termes avec certaines requêtes et utilise ces contrats. Du fait de la centralisation de la plateforme, les mécanismes d'authentification peuvent être moins fiables que dans les cryptomonnaies.
Prenons l'exemple des fournisseurs de téléphonie mobile (différents opérateurs mobiles). Imaginons qu'un opérateur centralise sur ses serveurs le trafic transmis sous différents formats (appels vocaux, SMS, trafic Internet mobile, etc.) et selon différentes normes. Il conserve également un historique des soldes des utilisateurs. Ainsi, un fournisseur de téléphonie mobile peut établir des contrats de comptabilité et de paiement avec différentes conditions. Dans ce cas, des conditions telles que « envoyez un SMS avec tel code à tel numéro et vous recevrez telles conditions de distribution du trafic » sont facilement définies.
Autre exemple : les banques traditionnelles avec des fonctionnalités bancaires en ligne avancées et des contrats très simples tels que des paiements réguliers, la conversion automatique des paiements entrants, la déduction automatique des intérêts sur un compte spécifié, etc.
Si nous parlons de contrats intelligents avec un environnement d'exécution décentralisé, nous disposons d'un groupe de validateurs. Idéalement, n'importe qui peut devenir validateur. Grâce au protocole de synchronisation et au consensus des bases de données, nous disposons d'une base de données commune qui stockera désormais toutes les transactions avec des contrats strictement décrits, et non des requêtes conditionnelles dont les formats changent fréquemment, et qui ne sont pas soumises à une spécification ouverte. Dans ce cas, les transactions contiendront des instructions pour l'exécution du contrat conformément à une spécification stricte. Cette spécification est ouverte et, par conséquent, les utilisateurs de la plateforme peuvent eux-mêmes auditer et valider les contrats intelligents. Nous constatons ici que les plateformes décentralisées sont supérieures aux plateformes centralisées en termes d'indépendance et de tolérance aux pannes, mais leur conception et leur maintenance sont beaucoup plus complexes.
Contrats intelligents par la méthode de définition et de réalisation des conditions
Examinons maintenant de plus près les différences entre les contrats intelligents quant à la définition et à l'exécution de leurs conditions. Nous nous intéresserons ici aux contrats intelligents programmés arbitrairement et Turing-complets. Un contrat intelligent Turing-complet permet de définir presque n'importe quel algorithme comme conditions d'exécution : écrire des cycles, certaines fonctions de calcul de probabilités, etc., jusqu'à vos propres algorithmes de signature électronique. Il s'agit ici d'une écriture logique véritablement arbitraire.
Il existe également des contrats intelligents arbitraires, mais non Turing-complets. C'est le cas de Bitcoin et de Litecoin, qui possèdent leur propre script. Cela signifie que vous ne pouvez utiliser que certaines opérations dans n'importe quel ordre, mais vous ne pouvez plus écrire de cycles ni vos propres algorithmes.
Il existe également des plateformes de contrats intelligents qui implémentent des contrats intelligents préinstallés. Parmi elles, Bitshares et Steemit. Bitshares propose plusieurs contrats intelligents pour le trading, la gestion de compte et la gestion de la plateforme elle-même et de ses paramètres. Steemit est une plateforme similaire, mais elle n'est plus axée sur l'émission de jetons et le trading comme Bitshares, mais sur le blogging, c'est-à-dire qu'elle stocke et traite du contenu de manière décentralisée.
Les contrats Turing-complets arbitraires incluent la plateforme Ethereum et RootStock, qui est encore en développement. Nous nous attarderons donc plus en détail sur la plateforme de contrats intelligents Ethereum ci-dessous.
Contrats intelligents par méthode d'initiation
Selon leur méthode d'initiation, les contrats intelligents peuvent être divisés en au moins deux groupes : automatisés et manuels (non automatisés). Les contrats automatisés se caractérisent par leur exécution entièrement automatique, tous paramètres et conditions étant connus. Autrement dit, ils ne nécessitent pas d'envoi de transactions supplémentaires ni de commission supplémentaire pour chaque exécution ultérieure. La plateforme dispose de toutes les données nécessaires pour calculer le déroulement du contrat intelligent. La logique n'est pas arbitraire, mais prédéfinie et tout est prévisible. Autrement dit, la complexité du contrat intelligent peut être anticipée, une commission fixe est appliquée et tous les processus de mise en œuvre sont plus efficaces.
Pour les contrats intelligents programmés arbitrairement, l'exécution n'est pas automatisée. Pour initier un tel contrat intelligent, il faut créer une nouvelle transaction à chaque étape, qui appellera l'étape d'exécution ou la méthode suivante du contrat intelligent, payer la commission correspondante et attendre la confirmation de la transaction. L'exécution peut être réussie ou non, car le code du contrat intelligent est arbitraire et des événements imprévisibles peuvent survenir, comme une boucle éternelle, l'absence de certains paramètres et arguments, des événements exceptionnels non gérés, etc.
Comptes Ethereum
Types de comptes Ethereum
Voyons quels comptes existent sur la plateforme Ethereum. Il n'existe que deux types de comptes, et aucune autre option n'est disponible. Le premier est appelé compte utilisateur, le second est un compte de contrat. Voyons en quoi ils diffèrent.
Le compte utilisateur est géré uniquement par la clé personnelle de signature électronique. Le titulaire du compte génère sa propre paire de clés pour la signature électronique grâce à l'algorithme ECDSA (Elliptic Curve Digital Signature Algorithm). Seules les transactions signées avec cette clé peuvent modifier l'état du compte.
Un compte de contrat intelligent possède sa propre logique. Il ne peut être géré qu'à l'aide d'un code prédéfini qui définit entièrement son comportement : comment il gérera ses cryptomonnaies dans certaines circonstances, à l'initiative de quel utilisateur, et sous quelles conditions supplémentaires ces cryptomonnaies seront distribuées. Si certains points ne sont pas prévus par les développeurs dans le code, des problèmes peuvent survenir. Par exemple, un contrat intelligent peut se retrouver dans un état où il n'accepte aucune exécution ultérieure de la part d'un utilisateur. Dans ce cas, les cryptomonnaies seront gelées, car le contrat intelligent ne prévoit aucune sortie de cet état.
Comment les comptes Ethereum sont créés
Dans le cas d'un compte utilisateur, le propriétaire génère lui-même une paire de clés à l'aide d'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 n'est plus utilisé, comme dans Bitcoin, mais un hachage simple par la fonction Keccak est fourni sur une longueur de 256 bits. Les bits de poids faible sont supprimés de la valeur résultante, soit 160 bits de poids faible de la valeur de sortie de la fonction de hachage. On obtient ainsi une adresse dans Ethereum. En réalité, elle occupe 20 octets.
Notez que l'identifiant de compte dans Ethereum est codé en hexadécimal sans somme de contrôle, contrairement à Bitcoin et à de nombreux autres systèmes, où l'adresse est codée en base 58 avec une somme de contrôle ajoutée. Il faut donc être prudent lorsque vous manipulez des identifiants de compte dans Ethereum : la moindre erreur d'identifiant peut entraîner la perte de jetons.
Il y a une caractéristique importante et c'est que le compte utilisateur au niveau de la base de données générale est créé au moment où il accepte le premier paiement entrant.
Une approche complètement différente est utilisée pour créer un compte de contrat intelligent. Dans un premier temps, l'un des utilisateurs écrit le code source du contrat intelligent, puis le transmet à un compilateur dédié à la plateforme Ethereum, obtenant ainsi le bytecode pour la machine virtuelle Ethereum. Le bytecode obtenu est placé dans un champ de transaction spécifique et certifié au nom du compte de l'initiateur. Ensuite, cette transaction est distribuée sur le réseau et le code du contrat intelligent est déposé. La commission de transaction, et donc d'exécution du contrat, est déduite du solde du compte de l'initiateur.
Chaque contrat intelligent contient nécessairement son propre constructeur (de ce contrat). Il peut être vide ou contenir du contenu. Une fois le constructeur exécuté, l'identifiant du compte du contrat intelligent est créé, permettant d'envoyer des cryptomonnaies, d'appeler certaines méthodes du contrat intelligent, etc.
Structure des transactions Ethereum
Pour clarifier les choses, nous commencerons par examiner la structure d’une transaction Ethereum et un exemple de code de contrat intelligent.
Une transaction Ethereum se compose de plusieurs champs. Le premier est le nonce, qui correspond au numéro de série de la transaction relatif au compte qui la distribue et en est l'auteur. Ce numéro est nécessaire pour distinguer les transactions en double, c'est-à-dire pour exclure le cas où la même transaction est acceptée deux fois. Grâce à un identifiant, chaque transaction possède une valeur de hachage unique.
Vient ensuite un champ comme celui-ci : prix du gazIl s'agit du prix auquel la monnaie de base Ethereum est convertie en gaz, utilisé pour financer l'exécution du contrat intelligent et l'allocation des ressources de la machine virtuelle. Qu'est-ce que cela signifie ?
Dans Bitcoin, les frais sont payés directement avec la monnaie de base, le Bitcoin lui-même. Cela est possible grâce à un mécanisme de calcul simple : nous payons uniquement pour la quantité de données contenues dans la transaction. Dans Ethereum, la situation est plus complexe, car il est très difficile de baser le volume de données de la transaction. Ici, une transaction peut également contenir du code de programme qui sera exécuté sur une machine virtuelle, et chaque opération de machine virtuelle peut avoir une complexité différente. Certaines opérations allouent également de la mémoire à des variables. Leur complexité propre détermine le paiement de chaque opération.
Le coût de chaque opération en équivalent gaz sera constant. Il est introduit spécifiquement pour déterminer le coût constant de chaque opération. En fonction de la charge du réseau, le prix du gaz, c'est-à-dire le coefficient selon lequel la devise de base sera convertie en cette unité auxiliaire pour payer la commission, variera.
La transaction Ethereum présente une autre caractéristique : le bytecode qu'elle contient et qui doit être exécuté dans la machine virtuelle est exécuté jusqu'à ce qu'elle aboutisse à un résultat (succès ou échec) ou jusqu'à ce qu'un certain nombre de jetons alloués au paiement de la commission soient épuisés. C'est précisément pour éviter que toutes les pièces du compte de l'expéditeur soient dépensées pour la commission en cas d'erreur (par exemple, un cycle interminable dans la machine virtuelle) que le champ suivant existe : démarrer le gaz (souvent appelée limite de gaz) - elle détermine le montant maximum de pièces qu'un expéditeur est prêt à dépenser pour effectuer une transaction particulière.
Le champ suivant est appelé adresse de destinationL'adresse du destinataire des pièces ou celle d'un contrat intelligent spécifique dont les méthodes seront appelées est saisie ici. Vient ensuite le champ La valeur, où le montant des pièces envoyées à l'adresse de destination est saisi.
Ensuite, il y a un domaine intéressant appelé données,, où la structure entière est saisie. Il ne s'agit pas d'un champ séparé, mais d'une structure complète dans laquelle le code de la machine virtuelle est défini. Des données arbitraires peuvent y être placées ; des règles spécifiques s'appliquent.
Et le dernier champ s'appelle SignatureIl contient simultanément la signature électronique de l'auteur de la transaction et la clé publique qui servira à la vérifier. La clé publique permet d'obtenir l'identifiant du compte de l'expéditeur de la transaction, ce qui permet d'identifier de manière unique le compte de l'expéditeur dans le système. Nous avons découvert l'essentiel de la structure de la transaction.
Exemple de code de contrat intelligent dans Solidity
Examinons maintenant de plus près le contrat intelligent le plus simple à l’aide d’un 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);
}
}Ci-dessus se trouve un code source simplifié qui peut contenir les pièces des utilisateurs et les restituer à la demande.
Il existe donc une banque de contrats intelligents qui exécute les fonctions suivantes : elle accumule des pièces sur son solde, c'est-à-dire que lors de la confirmation d'une transaction et de la mise en place d'un tel contrat intelligent, un nouveau compte est créé, qui peut contenir des pièces sur son solde ; elle se souvient des utilisateurs et de la répartition des pièces entre eux ; elle dispose de plusieurs méthodes de gestion des soldes, c'est-à-dire qu'il est possible de reconstituer, de retirer et de vérifier le solde de l'utilisateur.
Examinons chaque ligne du code source. Ce contrat comporte des champs constants. L'un d'eux, correspondant au type d'adresse, est appelé « propriétaire ». Le contrat mémorise l'adresse de l'utilisateur qui a créé ce contrat intelligent. Une structure dynamique stocke ensuite la correspondance entre les adresses et les soldes des utilisateurs.
Vient ensuite la méthode Bank, qui porte le même nom que le contrat. Il s'agit donc de son constructeur. Le propriétaire de la variable reçoit alors l'adresse de celui qui a placé ce contrat intelligent sur le réseau. C'est la seule action qui se produit dans ce constructeur. Autrement dit, msg correspond précisément aux données transférées à la machine virtuelle avec la transaction contenant l'intégralité du code de ce contrat. Par conséquent, msg.sender est l'auteur de la transaction qui place ce code. Il sera le propriétaire du contrat intelligent.
La méthode de dépôt permet de transférer une certaine quantité de jetons sur le compte du contrat via une transaction. Dans ce cas, le contrat intelligent, à la réception de ces jetons, les laisse sur son solde, mais enregistre dans la structure du solde l'expéditeur exact de ces jetons, afin de savoir à qui ils appartiennent.
La méthode suivante, appelée « retirer », prend un paramètre : le montant de pièces que l'utilisateur souhaite retirer de cette banque. Elle vérifie si le solde de l'utilisateur qui appelle cette méthode est suffisant pour l'envoyer. Si tel est le cas, le contrat intelligent renvoie ce montant à l'appelant.
Vient ensuite la méthode permettant de vérifier le solde actuel de l'utilisateur. L'utilisateur qui appelle cette méthode sera utilisé pour obtenir ce solde dans le contrat intelligent. Il est à noter que le modificateur de cette méthode est view. Cela signifie que la méthode elle-même ne modifie en rien les variables de sa classe et qu'il s'agit d'une méthode en lecture seule. Aucune transaction distincte n'est créée pour appeler cette méthode, aucune commission n'est versée et tous les calculs sont effectués localement, après quoi l'utilisateur reçoit le résultat.
La méthode kill est nécessaire pour détruire l'état du contrat intelligent. Une vérification supplémentaire est effectuée pour déterminer si l'appelant de cette méthode est le propriétaire du contrat. Si tel est le cas, le contrat s'autodétruit et la fonction de destruction prend comme paramètre l'identifiant du compte auquel le contrat enverra toutes les pièces restantes. Dans ce cas, les pièces restantes seront automatiquement envoyées à l'adresse du propriétaire du contrat.
Comment fonctionne un nœud Ethereum complet ?
Examinons schématiquement comment ces contrats intelligents sont exécutés sur la plateforme Ethereum et comment fonctionne un nœud de réseau complet.
Un nœud Ethereum complet doit avoir au moins quatre modules.
Le premier, comme pour tout protocole décentralisé, est le module réseau P2P : un module permettant la connexion réseau et la collaboration avec d'autres nœuds, où sont échangés des blocs, des transactions et des informations sur ces nœuds. Il s'agit d'un composant traditionnel de toutes les cryptomonnaies décentralisées.
Ensuite, nous avons un module pour stocker les données de la blockchain, les traiter, choisir une branche prioritaire, ajouter des blocs, dissocier des blocs, vérifier ces blocs, etc.
Le troisième module s'appelle EVM (Ethereum Virtual Machine) - il s'agit de machine virtuelleCe module reçoit le bytecode d'une transaction Ethereum. Il reçoit l'état actuel d'un compte spécifique et effectue des modifications d'état en fonction du bytecode reçu. La version de la machine virtuelle doit être identique sur chaque nœud du réseau. Les calculs effectués sur chaque nœud Ethereum sont identiques, mais ils s'exécutent de manière asynchrone : certains nœuds vérifient et acceptent la transaction en premier, en exécutant tout le code qu'elle contient, tandis que d'autres le font ultérieurement. Ainsi, lorsqu'une transaction est créée, elle est propagée sur le réseau, les nœuds l'acceptent et, au moment de la vérification, tout comme Bitcoin Script est exécuté sur Bitcoin, le bytecode de la machine virtuelle est exécuté ici.
Une transaction est considérée comme vérifiée si tout le code qu'elle contient a été exécuté et qu'un nouvel état d'un compte a été généré et enregistré jusqu'à ce qu'il soit clairement établi si la transaction a été appliquée ou non. Si la transaction a été appliquée, cet état est considéré non seulement comme exécuté, mais aussi pertinent. Une base de données stocke l'état de chaque compte pour chaque nœud du réseau. Comme tous les calculs sont effectués de la même manière et que l'état de la blockchain est le même, la base de données contenant les états de tous les comptes sera également la même pour chaque nœud.
Mythes et limites des contrats intelligents
En ce qui concerne les limitations qui existent pour les plateformes de contrats intelligents de type Ethereum, les suivantes peuvent être citées :
- exécution de code;
- allouer de la mémoire ;
- données de la blockchain;
- envoyer des paiements ;
- créer un nouveau contrat ;
- appeler d'autres contrats.
Examinons les limites imposées aux machines virtuelles et, par conséquent, dissipons certains mythes concernant les contrats intelligents. Sur une machine virtuelle, qui peut être installée non seulement sur Ethereum, mais aussi sur des plateformes similaires, il est possible d'effectuer des opérations logiques arbitraires : écrire du code et l'exécuter, et allouer de la mémoire supplémentaire. Cependant, la commission est payée séparément pour chaque opération et pour chaque unité de mémoire supplémentaire allouée.
Ensuite, la machine virtuelle peut lire les données de la base de données blockchain afin de les utiliser comme déclencheur pour exécuter une logique de contrat intelligent. Elle peut créer et envoyer des transactions, créer de nouveaux contrats et appeler les méthodes d'autres contrats intelligents déjà publiés sur le réseau : exist, available, etc.
Le mythe le plus répandu est que les contrats intelligents Ethereum peuvent utiliser les informations de n'importe quelle ressource Internet selon leurs propres conditions. En réalité, une machine virtuelle ne peut pas envoyer de requête réseau à une source d'information externe sur Internet. Autrement dit, il est impossible d'écrire un contrat intelligent qui répartirait la valeur entre les utilisateurs en fonction, par exemple, de la météo, du vainqueur d'un championnat ou d'un événement extérieur, car les informations relatives à ces événements n'existent tout simplement pas dans la base de données de la plateforme. Autrement dit, rien à ce sujet n'est présent dans la blockchain. Si elles n'y figurent pas, la machine virtuelle ne peut pas les utiliser comme déclencheurs.
Inconvénients d'Ethereum
Énumérons les principaux. Le premier inconvénient réside dans les difficultés de conception, de développement et de test des contrats intelligents dans Ethereum (Ethereum utilise le langage Solidity pour les écrire). En effet, la pratique montre qu'un pourcentage très élevé d'erreurs est dû au facteur humain. C'est d'ailleurs le cas pour les contrats intelligents Ethereum déjà écrits, de complexité moyenne ou supérieure. Si la probabilité d'erreur est faible pour les contrats intelligents simples, les contrats complexes sont très souvent sujets à des erreurs pouvant entraîner le vol de fonds, leur blocage, leur destruction inattendue, 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 conçue par des humains. Elle peut exécuter des commandes arbitraires, et c'est là que réside la vulnérabilité : une série de commandes peut être configurée d'une certaine manière, ce qui peut entraîner des conséquences imprévues. C'est un domaine très complexe, mais plusieurs études montrent déjà que ces vulnérabilités existent dans la version actuelle du réseau Ethereum et qu'elles peuvent entraîner la défaillance de nombreux contrats intelligents.
Une autre difficulté majeure, qui peut être considérée comme un inconvénient, réside dans le fait qu'il est possible, d'un point de vue pratique ou technique, de conclure qu'en compilant le bytecode d'un contrat à exécuter sur une machine virtuelle, on peut définir un ordre spécifique d'opérations. Exécutées simultanément, ces opérations surchargeront considérablement la machine virtuelle et la ralentiront de manière disproportionnée par rapport à la commission payée pour leur exécution.
Par le passé, le développement d'Ethereum a déjà connu une telle période, au cours de laquelle de nombreuses personnes connaissant parfaitement le fonctionnement de la machine virtuelle ont découvert de telles vulnérabilités. En réalité, les transactions rapportaient une commission minime, mais ralentissaient pratiquement le fonctionnement de l'ensemble du réseau. Ces problèmes sont très difficiles à résoudre : il faut d'abord les identifier, ensuite ajuster le prix d'exécution de ces opérations et enfin, procéder à un hard fork, c'est-à-dire mettre à jour tous les nœuds du réseau vers une nouvelle version du logiciel, puis activer simultanément ces modifications.
En ce qui concerne Ethereum, de nombreuses recherches ont été effectuées, beaucoup d'expérience pratique a été acquise : à la fois positive et négative, mais il existe néanmoins encore des difficultés et des vulnérabilités qui doivent encore être traitées d'une manière ou d'une autre.
Alors, la partie thématique de l'article étant terminée, passons aux questions qui se posent assez souvent.
LES QUESTIONS LES PLUS FRÉQUENTES
— Si toutes les parties d’un contrat intelligent existant souhaitent modifier les termes, peuvent-elles annuler ce contrat intelligent à l’aide de la multi-signature, puis créer un nouveau contrat intelligent avec les termes mis à jour de son exécution ?
La réponse est double. Pourquoi ? D'une part, un contrat intelligent est défini une fois pour toutes et n'implique aucune modification. D'autre part, il peut comporter une logique pré-écrite permettant la modification totale ou partielle de certaines conditions. Autrement dit, si vous souhaitez modifier un élément de votre contrat intelligent, vous devez pré-écrire les conditions de mise à jour. Par conséquent, seule cette prudence permet d'organiser une mise à jour du contrat. Mais là encore, des problèmes peuvent survenir : une erreur peut entraîner une vulnérabilité. Par conséquent, ces éléments doivent être conçus et testés avec le plus grand soin.
— Et si le médiateur s'entend avec l'une des parties : séquestre ou contrat intelligent ? Un médiateur est-il obligatoire dans un contrat intelligent ?
Un médiateur n'est pas obligatoire dans un contrat intelligent. Il peut même ne pas exister. Si, dans le cas d'un séquestre, le médiateur s'entend avec l'une des parties, alors ce système perd brutalement toute sa valeur. Par conséquent, les médiateurs sont choisis de manière à bénéficier de la confiance de toutes les parties impliquées dans le processus. Par conséquent, vous ne transférerez pas de cryptomonnaies vers une adresse multisignature avec un médiateur auquel vous ne faites pas confiance.
— Est-il possible de transférer de nombreux jetons différents de votre adresse vers différentes adresses cibles, telles que des adresses d'échange où ces jetons sont échangés, dans une seule transaction Ethereum ?
C'est une bonne question, qui concerne le modèle de transaction Ethereum et sa différence avec celui de Bitcoin. Et cette différence est fondamentale. Si, dans le modèle de transaction Ethereum, vous transférez simplement des jetons, ils sont transférés d'une adresse à une autre, sans modification, uniquement d'un montant spécifique spécifié. Autrement dit, il ne s'agit pas d'un modèle de sorties non dépensées (UTXO), mais d'un modèle de comptes et de soldes correspondants. Il est théoriquement possible d'envoyer plusieurs jetons simultanément lors d'une même transaction grâce à un contrat intelligent. Cependant, il faudra tout de même effectuer de nombreuses transactions, créer un contrat, y transférer des jetons et des jetons, puis appeler la méthode correspondante. Cela demande du temps et des efforts ; en pratique, cela ne fonctionne pas ainsi : tous les paiements Ethereum sont effectués dans des transactions distinctes.
— L’un des mythes concernant la plateforme Ethereum est qu’il est impossible de décrire de telles conditions qui dépendront des données d’une ressource Internet externe, alors que devrions-nous faire alors ?
La solution réside dans le fait que le contrat intelligent lui-même 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 contrats intelligents par des méthodes spécifiques. Le contrat lui-même considère comme vraies les données reçues des parties de confiance. Pour une plus grande fiabilité, un large groupe d'oracles est simplement sélectionné, minimisant ainsi le risque de collusion. Le contrat lui-même peut ne pas prendre en compte les données provenant d'oracles contradictoires.
Ce sujet fait l'objet d'une des conférences du cours en ligne sur la Blockchain — « ».
Source: habr.com
