Pourquoi de nombreux cas d'utilisation de contrats intelligents sont tout simplement impossibles

Le Dr Gideon Greenspan est le fondateur et PDG de Coin Sciences, la société à l'origine de la plateforme MultiChain pour les blockchains privées.

Dans cet article Analyses , Greenspan discute des contrats intelligents basés sur la blockchain et des raisons pour lesquelles cette application de la Technologies pourrait souffrir d'attentes exagérées.

En tant que développeur d'une plateforme blockchain populaire, on me demande parfois si les contrats intelligents de type Ethereum figurent sur la feuille de route de MultiChain. La réponse que je donne toujours est : « Non, ou du moins pas encore ».

Mais dans le monde en effervescence des blockchains,contrats intelligents Les blockchains autorisées de type Bitcoin sont à la mode, alors pourquoi pas ? Le problème est que, si nous connaissons désormais trois cas d'utilisation pertinents pour les blockchains autorisées de type Bitcoin (provenance, tenue de registres d'entreprise et Finance légère), nous n'avons pas encore trouvé d'équivalent. Ethereumcontrats intelligents.

Ce n'est pas que les gens ne comprennent T ce qu'ils attendent des contrats intelligents. C'est plutôt que beaucoup de ces idées sont tout simplement impossibles. Lorsque les gens intelligents entendent le terme « contrats intelligents », leur imagination a tendance à s'emballer. Ils imaginent des logiciels intelligents autonomes, partant à la découverte du monde et emportant des données avec eux. Malheureusement, la réalité des contrats intelligents est plus terre à terre.

Un contrat intelligent est un morceau de code stocké sur une blockchain, déclenché par des transactions blockchain et qui lit et écrit des données dans la base de données de cette blockchain. C'est tout. Vraiment.

Un contrat intelligent est simplement un nom sophistiqué pour du code qui s'exécute sur une blockchain et interagit avec son état. Et quel est ce code ? C'est du Pascal, du Python, du PHP, du Java, du Fortran, du C++. Pour les bases de données, ce sont des procédures stockées écrites dans une extension de SQL.

Tous ces langages sont fondamentalement équivalents et résolvent les mêmes types de problèmes de la même manière. Bien sûr, chacun a ses forces et ses faiblesses : créer un site web en C ou compresser une vidéo HD en Ruby serait une folie. Mais en principe, c'est possible si vous le souhaitez. Le prix à payer serait élevé en termes de commodité, de performances et, très probablement, de cheveux.

Le problème avec les contrats intelligents n’est T seulement que les attentes des gens sont exagérées, c’est que ces attentes conduisent beaucoup de gens à dépenser du temps et de l’argent sur des idées qui ne peuvent pas être mises en œuvre.

Il semble que les grandes entreprises disposent de ressources suffisantes pour parcourir un long chemin – depuis le moment où la direction générale découvre une nouvelle Technologies jusqu'à celui où ses avantages et ses limites sont pleinement compris. Notre propre expérience pourrait peut-être contribuer à raccourcir ce délai.

Au cours des neuf derniers mois, nous avons été confrontés à de nombreux cas d'utilisation de contrats intelligents et nous avons dû répondre, à maintes reprises, qu'ils ne pouvaient tout simplement pas être réalisés.

Nous avons ainsi identifié les trois idées fausses les plus répandues sur les contrats intelligents. Ces idées T fausses parce que la Technologies est immature ou que les outils ne sont pas encore disponibles.

Au contraire, ils méconnaissent les propriétés fondamentales du code qui réside dans une base de données et s’exécute de manière décentralisée.

1. Contacter des services externes

Souvent, le premier cas d'utilisation proposé est un contrat intelligent qui modifie son comportement en réponse à un événement externe. Par exemple, une Juridique d'assurance agricole versant des indemnités conditionnelles en fonction des précipitations d'un mois donné.

Le processus imaginé se déroule à peu près comme ceci : le contrat intelligent attend l'heure prédéterminée, récupère le bulletin météo auprès d'un service externe et se comporte de manière appropriée en fonction des données reçues.

Tout cela paraît simple, mais c'est aussi impossible. Pourquoi ? Parce qu'une blockchain est un système basé sur le consensus, ce qui signifie qu'elle ne fonctionne que si chaque nœud atteint un état identique après le traitement de chaque transaction et de chaque bloc.

Tout ce qui se passe sur une blockchain doit être complètement déterministe, sans aucun moyen pour que des différences s'infiltrent. Dès que deux nœuds honnêtes ne sont pas d'accord sur l'état de la chaîne, le système entier devient sans valeur.

Rappelons maintenant que les contrats intelligents sont exécutés indépendamment par chaque nœud d'une chaîne. Par conséquent, si un contrat intelligent récupère des informations d'une source externe, cette récupération est effectuée de manière répétée et séparée par chaque nœud. Cependant, comme cette source est externe à la blockchain, il n'est pas garanti que chaque nœud reçoive la même réponse.

Il se peut que la source modifie sa réponse entre les requêtes des différents nœuds, ou qu'elle devienne temporairement indisponible. Dans tous les cas, le consensus est rompu et la blockchain entière est détruite.

Alors, quelle est la solution ? En fait, c'est assez simple. Au lieu qu'un contrat intelligent initie la récupération de données externes, une ou plusieurs parties de confiance (« oracles ») créent une transaction qui intègre ces données dans la chaîne. Chaque nœud disposera d'une copie identique de ces données, ce qui permettra leur utilisation en toute sécurité dans le calcul d'un contrat intelligent.

En d’autres termes, un oracle pousse les données sur la blockchain plutôt qu’un contrat intelligent qui les récupère.

Un problème similaire se pose lorsque des contrats intelligents provoquent des Événements dans le monde extérieur. Par exemple, beaucoup apprécient l'idée d'un contrat intelligent qui appelle l'API d'une banque pour transférer de l'argent. Mais si chaque nœud exécute indépendamment le code de la chaîne, qui est responsable de l'appel de cette API ?

Si la réponse est un ONE nœud, que se passe-t-il si ce nœud particulier dysfonctionne, volontairement ou non ? Et si la réponse est chaque nœud, pouvons-nous lui faire confiance avec le mot de passe de cette API ? Et voulons-nous vraiment que l'API soit appelée des centaines de fois ? Pire encore, si le contrat intelligent a besoin de savoir si l'appel d'API a réussi, nous revenons au problème de la dépendance aux données externes.

Comme précédemment, une solution simple est disponible. Au lieu que le contrat intelligent appelle une API externe, nous utilisons un service de confiance qui surveille l'état de la blockchain et effectue certaines actions en conséquence. Par exemple, une banque pourrait surveiller proactivement une blockchain et effectuer des transferts d'argent reproduisant les transactions en chaîne. Cela ne présente aucun risque pour le consensus de la blockchain, car la chaîne joue un rôle entièrement passif.

En examinant ces deux solutions de contournement, nous pouvons faire quelques observations.

Premièrement, ils nécessitent tous deux une entité de confiance pour gérer les interactions entre la blockchain et le monde extérieur. Bien que cela soit techniquement possible, cela compromet l'objectif d'un système décentralisé.

Deuxièmement, les mécanismes utilisés dans ces solutions de contournement sont des exemples simples de lecture et d'écriture dans une base de données. Un oracle fournissant des informations externes les écrit simplement dans la chaîne. De même, un service reproduisant l'état de la blockchain dans le monde réel ne fait rien d'autre que lire cette chaîne. Autrement dit, toute interaction entre une blockchain et le monde extérieur se limite aux opérations habituelles de la base de données.

Nous parlerons davantage de ce fait plus tard.

2. Application des paiements en chaîne

Voici une autre proposition que l'on entend souvent : utiliser un contrat intelligent pour automatiser le paiement des coupons d'une « BOND intelligente ». L'idée est que le code du contrat intelligent initie automatiquement les paiements au moment opportun, évitant ainsi les processus manuels et garantissant que l'émetteur ne puisse pas faire défaut.

Bien sûr, pour que cela fonctionne, les fonds utilisés pour effectuer les paiements doivent également résider dans la blockchain, sinon un contrat intelligent ne pourrait pas garantir leur paiement.

Rappelons qu'une blockchain n'est qu'une base de données, en l'occurrence un registre financier contenant l' BOND émise et des liquidités. Ainsi, lorsque nous parlons de paiements de coupons, nous parlons en réalité d'opérations de base de données qui s'exécutent automatiquement à un moment convenu.

Bien que cette automatisation soit techniquement réalisable, elle présente des difficultés financières. Si les fonds utilisés pour le paiement des coupons sont contrôlés par le contrat intelligent de l'obligation, ces paiements peuvent effectivement être garantis. Mais cela signifie également que ces fonds ne peuvent être utilisés par l'émetteur de BOND à d'autres fins. Et si ces fonds ne sont T sous le contrôle du contrat intelligent, il est impossible de garantir le paiement.

En d'autres termes, une BOND intelligente est soit inutile pour l'émetteur, soit inutile pour l'investisseur. Et à bien y réfléchir, c'est un résultat tout à fait évident.

Du point de vue d'un investisseur, l'intérêt d'une BOND réside dans son taux de rendement attractif, au prix d'un certain risque de défaut. Quant à l'émetteur, l'objectif d'une obligation est de lever des fonds pour une activité productive, mais quelque peu risquée, comme la construction d'une nouvelle usine.

L'émetteur BOND n'a aucun moyen d'utiliser les fonds levés tout en garantissant le remboursement de l'investisseur. Il n'est donc pas surprenant que le lien entre risque et rendement ne soit pas un problème que les blockchains peuvent résoudre.

3. Cacher des données confidentielles

Comme je l’ai déjà écrit, le plus grand défi du déploiement des blockchains est la transparence radicale qu’elles offrent.

Par exemple, si dix banques mettent en place une blockchain ensemble et que deux d'entre elles effectuent une transaction bilatérale, celle-ci sera immédiatement visible par les huit autres. Bien qu'il existe différentes stratégies pour atténuer ce problème, aucune ne surpasse la simplicité et l'efficacité d'une base de données centralisée dans laquelle un administrateur de confiance contrôle totalement qui peut voir quoi.

Certains pensent que les contrats intelligents peuvent résoudre ce problème. Ils partent du principe que chaque contrat intelligent contient sa propre base de données miniature, sur laquelle il a un contrôle total. Toutes les opérations de lecture et d'écriture sur cette base de données sont gérées par le code du contrat, ce qui empêche un contrat de lire directement les données d'un autre. (Ce couplage étroit entre données et code est appelé encapsulation et constitue le fondement du paradigme populaire de la programmation orientée objet).

Alors, si un contrat intelligent T peut accéder aux données d'un autre, avons-nous résolu le problème de la confidentialité de la blockchain ? Est-il judicieux de parler de dissimulation d'informations dans un contrat intelligent ? Malheureusement, la réponse est non.

Car même si un contrat intelligent ne peut T lire les données d'un autre, celles-ci sont néanmoins stockées sur chaque nœud de la chaîne. Pour chaque participant à la blockchain, elles sont stockées dans la mémoire ou le disque d'un système qu'il contrôle entièrement. Et rien ne l'empêche de lire les informations de son propre système, s'il le souhaite.

Cacher des données dans un contrat intelligent est presque aussi sûr que de les cacher dans le code HTML d'une page web. Bien sûr, les utilisateurs web ordinaires ne les verront T , car elles ne s'affichent pas dans leur navigateur. Mais il suffit qu'un navigateur web ajoute une fonction « Afficher la source » (comme c'est le cas pour tous) pour que les informations deviennent visibles universellement.

De même, pour les données cachées dans les contrats intelligents, il suffit que quelqu’un modifie son logiciel blockchain pour afficher l’état complet du contrat, et tout semblant de secret est perdu.

Un programmeur à peu près compétent pourrait faire cela en une heure environ.

À quoi servent les contrats intelligents

Compte tenu de toutes les fonctionnalités que les contrats intelligents ne peuvent pas accomplir, on peut se demander à quoi ils servent réellement. Mais pour répondre à cette question, il faut revenir aux fondamentaux des blockchains. En résumé, une blockchain permet à des entités qui ne se font pas confiance de partager directement et en toute sécurité une base de données, sans nécessiter d'administrateur central.

Les blockchains permettent la désintermédiation des données, ce qui peut conduire à des économies significatives en termes de complexité et de coûts.

Toute base de données est modifiée par des « transactions », qui contiennent un ensemble de modifications apportées à cette base de données, dont l'ensemble doit réussir ou échouer. Par exemple, dans un grand livre financier, un paiement d' ALICE à Bob est représenté par une transaction qui (a) vérifie si ALICE dispose de fonds suffisants, (b) déduit une somme du compte d'Alice et (c) ajoute la même somme à celui de Bob.

Dans une base de données centralisée classique, ces transactions sont créées par une autorité de confiance unique. En revanche, dans une base de données partagée basée sur une blockchain, les transactions peuvent être créées par n'importe lequel des utilisateurs de cette blockchain. Et comme ces utilisateurs ne se font pas entièrement confiance, la base de données doit contenir des règles qui restreignent les transactions effectuées.

Par exemple, dans un registre financier peer-to-peer, chaque transaction doit préserver la quantité totale de fonds, sinon les participants pourraient se donner librement autant d’argent qu’ils le souhaitent.

On peut imaginer différentes manières d'exprimer ces règles, mais pour l'instant, deux paradigmes dominent, inspirés respectivement de Bitcoin et Ethereum. La méthode Bitcoin , que l'on pourrait appeler « contraintes de transaction », évalue chaque transaction en fonction : (a) des entrées de base de données supprimées par cette transaction et (b) des entrées créées.

Dans un grand livre financier, la règle stipule que le montant total des fonds dans les écritures supprimées doit correspondre au total de celles créées. (Nous considérons que la modification d'une écriture existante équivaut à la supprimer et à en créer une ONE à sa place).

Le deuxième paradigme, issu d' Ethereum, est celui des contrats intelligents. Ce principe stipule que toute modification des données d'un contrat doit être effectuée par son code. (Dans le contexte des bases de données traditionnelles, on peut considérer cela comme une procédure stockée forcée.) Pour modifier les données d'un contrat, les utilisateurs de la blockchain envoient des requêtes à son code, qui détermine si et comment ces requêtes doivent être satisfaites.

Comme dans cet exemple, le contrat intelligent d'un grand livre financier effectue les trois mêmes tâches que l'administrateur d'une base de données centralisée : vérifier la disponibilité des fonds, déduire d' un compte et ajouter à un autre.

Ces deux paradigmes sont efficaces et présentent chacun leurs avantages et leurs inconvénients. En résumé, les contraintes de transaction de type Bitcoin offrent une concurrence et des performances supérieures, tandis que les contrats intelligents de type Ethereum offrent une plus grande flexibilité.

Pour revenir à la question de savoir à quoi servent les contrats intelligents : les contrats intelligents sont destinés aux cas d'utilisation de la blockchain qui ne peuvent T être mis en œuvre avec des contraintes de transaction.

Compte tenu de ce critère d’utilisation des contrats intelligents, je n’ai pas encore vu de cas d’utilisation solide pour les blockchains autorisées qui soit éligible.

Toutes les applications blockchain convaincantes que je connais peuvent être implémentées avec des transactions de type Bitcoin, qui gèrent les autorisations et le stockage général des données, ainsi que la création, le transfert, le séquestre, l'échange et la destruction d'actifs. Néanmoins, de nouveaux cas d'utilisation apparaissent encore, et je T surpris que certains nécessitent la puissance des contrats intelligents. Ou, à tout le moins, une extension du paradigme Bitcoin .

Quelle que soit la réponse, l’essentiel à retenir est que les contrats intelligents ne sont ONE méthode permettant de restreindre les transactions effectuées dans une base de données.

C'est sans aucun doute utile et essentiel pour sécuriser le partage de la base de données. Mais les contrats intelligents ne peuvent rien faire d'autre et ne peuvent certainement pas échapper aux limites de la base de données dans laquelle ils résident.

Image de crayon et de gommevia Shutterstock