L'un des objectifs des contrats intelligents est l'automatisation des transactions de paiement entre contreparties. Notre service de paiement blockchain
wirech fonctionne
également sur ce marché. Malgré la promesse de contrats intelligents, l'auteur du matériel analyse les lacunes de cette technologie.
En tant que développeur de la plateforme de blockchain populaire, on me demande parfois s'il y a une place pour les contrats intelligents dans les plans de développement de notre service Multichain, similaires à ceux utilisés dans Ethereum. La réponse sonne toujours: "Non, ou du moins pas maintenant."
Mais dans le monde bruyant du battage médiatique des blockchains, les contrats intelligents
sont considérés comme quelque chose de très cool. Pourquoi n'y a-t-il toujours pas de réponse? Eh bien, le problème est que si dans le cas de bitcoins contrôlés comme le bitcoin, nous connaissons au moins trois scénarios puissants de leur application pratique (suivi de l'historique d'origine, stockage des documents de l'entreprise, facilitation de l'organisation des systèmes financiers), alors pour
les contrats intelligents à l'antenne équivalents en efficacité les cas n'existent tout simplement pas.
Ce n'est pas que les gens ne comprennent pas ce qu'ils veulent des contrats intelligents. Le problème est plutôt que tant de ces idées ne sont tout simplement pas réalisables. Lorsque les gens intelligents entendent le terme contrats intelligents, ils ont tendance à laisser libre cours à leur imagination. Dessinez dans la tête des images d'un logiciel autonome intelligent, surfez sur une vague de données et connectez-vous pour résoudre des problèmes du monde réel. Malheureusement, la véritable image du fonctionnement des contrats intelligents est beaucoup plus prosaïque.
Un contrat intelligent est un morceau de code stocké sur la blockchain. Il est alimenté par des transactions blockchain et lit à partir de la blockchain ou y écrit des données. C’est tout. Ni plus ni moins.
Un contrat intelligent n'est qu'un nom sonore pour un code qui fonctionne sur la blockchain et interagit avec son état. Quel est ce code? Il s'agit de Pascal, Python ou PHP. Ou peut-être Java, Fortran ou C ++. Si vous pensez au format de la base de données, il peut être représenté sous la forme de procédures écrites dans une extension de SQL.
Fondamentalement, toutes ces langues sont équivalentes; elles résolvent les mêmes types de problèmes en utilisant les mêmes méthodes pour les résoudre. Bien sûr, chacun a ses forces et ses faiblesses. Vous seriez fou d'essayer de créer un site Web C ou de compresser une vidéo HD en Ruby. Mais au moins théoriquement, vous pouvez le faire si vous le souhaitez. Il vous suffirait de payer un prix élevé en termes de commodité, de performances et il est très probable que vous perdiez beaucoup de cheveux sur la tête.
Le problème des contrats intelligents réside non seulement dans des attentes excessivement élevées, mais aussi dans le fait que ces attentes conduisent au fait qu'un nombre considérable de personnes consacrent du temps et de l'argent à des idées qui ne se réaliseront probablement pas dans la pratique.
La pratique montre que les grandes entreprises, en règle générale, ont suffisamment de ressources pour faire du chemin depuis le moment où la haute direction apprend une nouvelle technologie jusqu'au moment où ses avantages et ses limites deviennent vraiment compris.
Au cours des neuf derniers mois, nous avons écouté beaucoup de présentations sur les scénarios possibles d'application de contrats intelligents, et il se trouve que nous avons répété à maintes reprises à leurs auteurs que ces idées ne pouvaient tout simplement pas se réaliser dans la vie réelle.
En conséquence, nous avons identifié les trois idées fausses les plus courantes sur le sujet des contrats intelligents. Ces idées ne sont pas vraies non pas parce que la technologie n'est pas encore assez mûre ou pas parce que nous n'avons pas encore d'outils.
Au lieu de cela, ils sont basés sur une mauvaise compréhension des propriétés fondamentales du code qui vit dans une base de données et est traité de manière décentralisée.
1. Interaction avec les services externes
Souvent, vous pouvez entendre l'offre d'utiliser des contrats intelligents qui modifient leur comportement en réponse à un événement externe. Par exemple, une police d'assurance agricole qui effectue des paiements en fonction de la quantité de pluie tombée au cours d'un mois donné.
Selon l'idée des auteurs de l'idée, le processus se déroule approximativement comme suit: un contrat intelligent attend un certain temps prédéterminé, reçoit un bulletin météo d'un service externe et se comporte conformément aux données reçues.
Cela semble assez simple. Simple et impossible à la fois. Pourquoi? Parce que la blockchain est un système basé sur le consensus, ce qui signifie qu'il ne fonctionnera que si chaque nœud de réseau atteint le même état après avoir traité chaque transaction et chaque bloc.
Toutes les opérations qui ont lieu sur la blockchain doivent être complètement déterminées, sans la moindre probabilité qu'une différence ne se glisse dans son travail. Dès que deux noeuds honnêtes prennent des positions différentes sur l'état de la chaîne, l'ensemble du système devient inutile.
Et maintenant, permettez-moi de vous rappeler que chaque nœud de chaîne exécute les contrats intelligents de manière indépendante. Cela signifie que si un contrat intelligent reçoit des informations d'une source externe, chaque nœud répète la procédure d'obtention des données indépendamment. Mais puisque la source est en dehors de la blockchain, il n'y a aucune garantie que chaque nœud recevra la même réponse.
Peut-être que la source changera sa réponse à un moment donné entre les demandes de deux nœuds différents, ou elle pourrait devenir temporairement indisponible. D'une manière ou d'une autre, le consensus ne sera pas atteint et l'ensemble de la blockchain cessera de fonctionner.
Comment sortir de la situation? Et la solution est en fait très simple. Il vous suffit de remplacer le processus de contact d'un contrat intelligent avec une source externe par une ou plusieurs parties de confiance (les soi-disant oracles) créant une transaction qui écrit les données nécessaires dans la chaîne. Ensuite, chaque nœud aura une copie identique des données, et elles pourront être utilisées dans les calculs du contrat intelligent.
En d'autres termes, au lieu d'un contrat intelligent qui «tire» des données de l'extérieur, l'oracle entrera ces mêmes données dans la blockchain.
Des problèmes similaires se posent en ce qui concerne les contrats intelligents qui déclenchent certains événements dans le monde extérieur. Par exemple, de nombreuses personnes aiment l'idée de contrats intelligents qui utilisent l'API de la banque pour transférer de l'argent. Mais si chaque nœud exécute le code de chaîne indépendamment, quel nœud sera chargé d'appeler l'API?
Si ce sera un seul nœud, que se passera-t-il si ce nœud particulier, délibérément ou involontairement, commence à échouer? Et si tous les nœuds seront contactés, pouvons-nous faire confiance à chaque nœud avec un mot de passe API? Et est-il justifié de passer des centaines d'appels au lieu d'un seul? Et pire encore: si un contrat intelligent doit déterminer le succès d'un appel API, nous sommes de nouveau confrontés au problème de la dépendance aux données externes.
Et il existe également une solution simple. Au lieu de demander à un contrat intelligent d'accéder à une API externe, nous pouvons utiliser un service de confiance qui surveille l'état de la chaîne de blocs et effectue certaines actions en réponse aux données reçues. Par exemple, une banque pourrait surveiller de manière proactive la blockchain et effectuer des transferts d'argent correspondant aux transactions approuvées dans la chaîne. Cette approche ne crée aucun risque pour parvenir à un consensus, car la chaîne dans ce modèle joue un rôle absolument passif.
Après avoir examiné les solutions proposées aux situations décrites ci-dessus, nous pouvons tirer quelques conclusions.
Premièrement, les deux approches nécessitent un tiers de confiance pour gérer les interactions entre la blockchain et le monde extérieur. Malgré la possibilité théorique de mettre en œuvre un tel modèle, toute décentralisation dans son cadre perd tout son sens.
Deuxièmement, les mécanismes utilisés dans ces exemples sont des exemples directs de lecture et d'écriture dans la base de données. L'oracle fournissant des informations externes les écrit simplement dans la chaîne. Un service qui répète l'état de la blockchain dans le monde réel ne fait que lire dans cette chaîne. En d'autres termes, toute interaction entre la blockchain et le monde extérieur se résume dans ce cas à des opérations de base de données normales.
Plus en détail, nous révélerons ce fait plus loin dans la matière.
2. Effectuer des paiements dans la chaîne
Autre suggestion que l'on entend assez souvent: l'utilisation de contrats intelligents pour automatiser les paiements sur les coupons des obligations dites intelligentes. L'essence de l'idée est d'initialiser automatiquement les paiements au moment requis par le contrat intelligent. Cela évitera le traitement manuel du paiement et garantira que l'émetteur ne peut pas faire défaut.
Bien sûr, pour que cette idée fonctionne, les fonds utilisés pour le paiement doivent également être à l'intérieur de la blockchain. Sinon, un contrat intelligent ne peut tout simplement pas garantir le paiement.
Souvenons-nous que la blockchain n'est qu'une base de données. Dans notre cas, un registre financier contenant des obligations émises et une caisse. Par conséquent, lorsque nous parlons de paiements de coupons, nous parlons en fait d'opérations de base de données effectuées automatiquement à l'heure convenue.
Bien qu'une telle automatisation soit réalisable d'un point de vue technique, des difficultés surviennent avec l'aspect financier du modèle. Si les fonds utilisés pour le paiement des coupons sont contrôlés par un contrat intelligent obligataire, ces paiements peuvent vraiment être garantis. Mais dans ce cas, l'émetteur d'obligations ne pourra pas utiliser ces fonds à d'autres fins. Et le retrait de fonds du contrôle d'un contrat intelligent annule toute garantie de leur paiement.
En d'autres termes, une obligation intelligente n'a de sens ni pour l'émetteur ni pour l'investisseur. Si vous réfléchissez à cette situation, alors une telle conclusion devient complètement évidente.
Du point de vue de l'investisseur, l'essence de l'achat d'obligations est la capacité de réaliser un profit attractif, s'il existe un risque de défaut acceptable. Pour l'émetteur, l'émission d'obligations a pour but de lever des fonds pour une activité productive mais quelque peu risquée, comme par exemple la construction d'une nouvelle usine.
L'émetteur n'a aucun moyen de lever des fonds et, en même temps, de garantir uniquement les paiements aux investisseurs. Je pense que personne ne sera surpris par le fait que la régularité existant entre risque et rentabilité ne figure pas dans la liste des tâches que les blockchains peuvent résoudre.
3. La nécessité de cacher les données sensibles
Comme je l'ai écrit plus tôt, le défi le plus sérieux auquel nous sommes confrontés lors du déploiement de chaînes de blocs est l'extrême degré de transparence qu'elles offrent.
Par exemple, si un groupe de 10 banques souhaite créer une blockchain ensemble, toutes les transactions bidirectionnelles dans cette blockchain deviennent immédiatement visibles pour les huit autres participants. Malgré l'existence de diverses stratégies qui permettent de niveler cet effet, aucune d'entre elles ne peut surpasser la simplicité et l'efficacité d'une base de données centralisée gérée par une certaine personne qui a un contrôle total sur les niveaux de visibilité et d'accès de tous les participants.
Certaines personnes pensent que les contrats intelligents peuvent résoudre ce problème. Leur raisonnement commence par le fait que chaque contrat intelligent contient sa propre base de données miniature et la contrôle complètement. Toutes les opérations de lecture et d'écriture dans cette base de données sont entièrement médiées par le code de contrat, ce qui exclut la situation où un contrat lit les données d'un autre. (Cette relation étroite entre les données et le code est appelée encapsulation. Elle sous-tend les paradigmes populaires de la programmation orientée objet).
Ainsi, aucun contrat intelligent ne peut accéder aux données d'autres contacts intelligents. Mais cela résout-il le problème de confidentialité au sein de la blockchain? Est-il judicieux de parler de cacher des informations dans un contrat intelligent? Malheureusement, la réponse est non.
Oui, un contrat intelligent ne peut pas lire les données d'autres contrats, cependant, ces copies de ces données sont toujours situées dans chaque nœud de réseau individuel. Chaque participant stocke ces données dans sa mémoire ou sur le disque dur du système, qui est sous son contrôle total. En conséquence, rien n'empêche ce participant de lire des informations dans son propre système si et quand il veut le faire.
Les tentatives de masquer des données dans un contrat intelligent sont comparables en termes de niveau de sécurité avec une tentative de les masquer dans le code HTML d'une page Web. Bien sûr, les utilisateurs Web ordinaires ne verront pas ces informations, car elles ne seront pas affichées dans la fenêtre du navigateur. Mais pour sa divulgation, il vous suffit de cliquer sur le bouton pour afficher le "code source", qui est dans tous les navigateurs modernes et les données deviennent immédiatement dans la paume de votre main.
De même, dans le cas de données cachées dans un contrat intelligent, il suffit de modifier le logiciel pour travailler avec la blockchain afin qu'il affiche le statut complet du contrat et que toute apparence de secret disparaisse immédiatement.
Tout programmeur de la classe moyenne fera face à cette tâche en moins d'une heure.
À quoi servent les contrats intelligents?
Après tout ce qui précède, une question raisonnable se pose: où en général les contrats intelligents peuvent-ils trouver application? Mais pour répondre à cette question, nous devons revenir mentalement aux concepts de base des blockchains. En bref, la blockchain permet à un groupe de personnes qui ne se font pas confiance de travailler directement, en toute sécurité et directement avec la base de données sans avoir besoin de se tourner vers un certain administrateur principal pour obtenir de l'aide.
Les chaînes de blocs vous permettent d'abandonner la médiation dans le travail avec les données, ce qui peut entraîner une simplification importante et des coûts plus bas.
Pour apporter une modification à une base de données, il est nécessaire d'effectuer une soi-disant transaction contenant un ensemble de modifications dans la base de données qui seront appliquées avec succès ou rejetées toutes ensemble. Prenons, par exemple, la situation du registre financier lorsque Alice effectue un paiement en faveur de Bob. Le paiement est présenté sous la forme d'une transaction qui: a) vérifie si Alice a suffisamment de fonds dans le compte, b) déduit le montant indiqué des fonds du compte d'Alice et c) ajoute le même montant au compte de Bob.
Dans une base de données centralisée régulière, ces transactions sont créées par un seul gestionnaire de confiance. En revanche, dans une base de données publique de type blockchain, les transactions peuvent être créées par n'importe quel utilisateur de blockchain. Et puisqu'il n'y a pas de confiance absolue entre ces utilisateurs, il devrait y avoir des règles dans la base de données qui imposent une restriction sur l'exécution des transactions.
Par exemple, dans le registre financier, dont tous les nœuds sont en position égale, les paramètres de chaque transaction ne doivent pas conduire à une violation du solde général des fonds. Sinon, les participants seront en mesure d'allouer librement autant d'argent qu'ils le souhaitent.
Il existe de nombreuses façons de se conformer à ces règles, mais deux paradigmes prévalant sous l'influence de Bitcoin et d'Ethereum dominent actuellement. La méthode Bitcoin, qui peut être appelée une «restriction de transaction» d'une autre manière, évalue chaque transaction du point de vue: a) des enregistrements de la base de données supprimés à l'aide de cette transaction et b) des enregistrements créés.
La règle est utilisée dans le registre financier: le montant total des fonds dans les enregistrements supprimés ne doit pas entrer en conflit avec le montant total dans les enregistrements créés. (une modification dans un enregistrement est considérée comme la suppression de cet enregistrement et sa recréation avec les valeurs nécessaires).
Le deuxième paradigme originaire d'Ethereum est celui des contrats intelligents. Selon elle, toutes les modifications des données du contrat doivent être effectuées par son code. (Dans le contexte des bases de données traditionnelles, on peut considérer qu'il s'agit d'une procédure stockée obligatoire) Pour modifier les données du contrat, les utilisateurs de la blockchain envoient des demandes à son code qui détermine s'il faut répondre à la demande et comment la faire.
À la lumière de l'exemple ci-dessus, un contrat intelligent pour le registre financier effectue les mêmes tâches que l'administrateur d'une base de données centralisée: vérifier la disponibilité d'un montant suffisant de fonds, les soustraire d'un compte et les ajouter à un autre.
Les deux paradigmes fonctionnent efficacement et chacun d'eux a ses avantages et ses inconvénients. En bref, la limitation des transactions de type bitcoin vous permet d'obtenir de meilleurs indicateurs d'accessibilité et de performances simultanées, tandis que les contrats intelligents de type éthereum offrent une plus grande flexibilité.
Par conséquent, revenons à la question de savoir à quoi servent les contrats intelligents: ils sont nécessaires lorsqu'il n'est pas possible de mettre en œuvre un cas de blockchain en utilisant une restriction de transaction.
Mais même après avoir décidé de ce critère pour l'utilisation des contrats intelligents, j'ai encore du mal à citer au moins un scénario de leur application pour les blockchains fermées, où l'approche traditionnelle du bitcoin ne serait vraiment pas applicable.
Tous les projets de blockchain vraiment intéressants que je connais peuvent être mis en œuvre en utilisant l'approche bitcoin, dans le cadre de laquelle il est possible de mettre en œuvre à la fois la séparation des droits d'accès et le stockage des données, ainsi que la création d'actifs, leur déplacement, dépôt, échange et destruction. Quoi qu'il en soit, de nouveaux cas d'utilisation apparaissent régulièrement et je ne serai pas surpris si certains d'entre eux nécessitent vraiment la puissance des contrats intelligents. Ou au moins une extension du paradigme Bitcoin.
D'une manière ou d'une autre, la règle clé dans toute situation est de se rappeler que les contrats intelligents ne sont qu'une des méthodes pour limiter l'exécution des transactions dans la base de données.
, , . - . , .
