Attention au contrat intelligent impossible

Les trois idées fausses les plus courantes sur les contrats intelligents

En tant que développeurs d’une plateforme blockchain populaire, on nous demande parfois si des contrats intelligents de type Ethereum sont sur le marché. MultiChain feuille de route. La réponse que je donne toujours est : non, ou du moins pas encore.

Mais dans le monde en vogue des blockchains, les contrats intelligents font fureur, alors pourquoi pas ? Eh bien, le problème est que, bien que nous connaissions désormais trois cas d'utilisation importants pour les blockchains autorisées de style Bitcoin (provenance, enregistrements inter-entreprises et financement léger), nous n'avons pas encore trouvé l'équivalent pour les contrats intelligents de style Ethereum.

Ce n’est pas que les gens manquent d’idées sur ce qu’ils veulent que les contrats intelligents fassent. C'est plutôt que tant de ces idées sont tout simplement impossibles. Vous voyez, lorsque les gens intelligents entendent le terme « contrats intelligents », leur imagination a tendance à se déchaîner. Ils évoquent le rêve d'un logiciel intelligent et autonome, partant à la découverte du monde et emportant ses données avec lui.

Malheureusement, la réalité des contrats intelligents est bien plus banale que tout cela :

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 ça. Vraiment. Un contrat intelligent n'est qu'un nom sophistiqué pour un code qui s'exécute sur une blockchain et interagit avec l'état de cette blockchain. Et quoi is code? C'est Pascal, c'est Python, c'est PHP. C'est Java, c'est Fortran, c'est C++. Si nous parlons de bases de données, c'est procédures stockées écrit dans une extension de SQL. Tous ces langages sont fondamentalement équivalents, résolvant les mêmes types de problèmes de la même manière. Bien sûr, chacun a ses forces et ses faiblesses : vous seriez fou de créer un site Web en C ou de compresser une vidéo HD en Ruby. Mais en principe au moins, vous pourriez si vous le vouliez. Vous paieriez simplement un lourd tribut en termes de commodité, de performances et très probablement de vos cheveux.

Le problème des contrats intelligents ne réside pas seulement dans le fait que les attentes des gens sont exagérées. C'est que ces attentes conduisent de nombreuses personnes à consacrer du temps et de l'argent à 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 – du moment où la haute direction découvre une nouvelle technologie jusqu'au moment où les avantages et les limites de cette technologie sont réellement compris. Peut-être que notre propre expérience peut contribuer à raccourcir ce délai.

Au cours des neuf derniers mois, de nombreux cas d'utilisation de contrats intelligents nous ont été présentés et nous nous sommes retrouvés à répondre, à maintes reprises, qu'ils ne pouvaient tout simplement pas être réalisés. En conséquence, nous avons identifié les trois idées fausses les plus répandues sur les contrats intelligents. Ces idées ne sont pas fausses parce que la technologie est immature ou que les outils ne sont pas encore disponibles. Au contraire, ils comprennent mal le propriétés fondamentales du code qui vit dans une base de données et s'exécute de manière décentralisée.

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 police d’assurance agricole qui verse des versements conditionnels en fonction de la quantité de précipitations au cours d’un mois donné. Le processus imaginé ressemble à ceci : le contrat intelligent attend jusqu'à l'heure prédéterminée, récupère le bulletin météo d'un service externe et se comporte de manière appropriée en fonction des données reçues.

Tout cela semble assez 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 avoir traité chaque transaction et chaque bloc. Tout ce qui se passe sur une blockchain doit être complètement déterministe, sans aucun moyen possible pour que des différences s'insinuent. Dès que deux nœuds honnêtes ne sont pas d'accord sur l'état de la chaîne, le système tout 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 certaines informations auprès 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. Mais comme cette 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 entre les demandes provenant de différents nœuds, ou peut-être deviendra-t-elle temporairement indisponible. Quoi qu’il en soit, le consensus est rompu et la blockchain entière meurt.

Alors, quelle est la solution de contournement ? En fait, c'est plutôt simple. Au lieu d'un contrat intelligent lançant 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 aura une copie identique de ces données, afin qu'elles puissent être utilisées 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 que sur un contrat intelligent tirant dans.

Lorsqu’il s’agit de contrats intelligents provoquant des événements dans le monde extérieur, un problème similaire apparaît. Par exemple, beaucoup aiment l'idée d'un contrat intelligent qui appelle l'API d'une banque afin de 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 juste un nœud, que se passe-t-il si ce nœud particulier tombe en panne, délibérément ou non ? Et si la réponse est à chaque nœud, pouvons-nous faire confiance à chaque nœud 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 API a réussi, on revient au problème de la dépendance aux données externes.

Comme auparavant, une solution de contournement simple est disponible. Au lieu du contrat intelligent appelant une API externe, nous utilisons un service de confiance qui surveille l'état de la blockchain et effectue certaines actions en réponse. Par exemple, une banque pourrait surveiller de manière proactive une blockchain et effectuer des transferts d’argent qui reflètent 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 regardant 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 lire et écrire une base de données. Un oracle qui fournit des informations externes écrit simplement ces informations dans la chaîne. Et un service qui reflète l’état de la blockchain dans le monde réel ne fait rien d’autre que lire cette chaîne. En d’autres termes, toute interaction entre une blockchain et le monde extérieur est limitée aux opérations régulières de base de données. Nous parlerons davantage de ce fait plus tard.

Appliquer les paiements en chaîne

Voici une autre proposition que l'on a tendance à entendre beaucoup : utiliser un contrat intelligent pour automatiser le paiement des coupons d'une « obligation intelligente ». L'idée est que le code du contrat intelligent lance automatiquement les paiements aux moments appropriés, évitant ainsi les processus manuels et garantissant que l'émetteur ne peut pas faire défaut.

Bien entendu, 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 maintenant qu'une blockchain n'est qu'une base de données, en l'occurrence un registre financier contenant l'obligation émise et des espèces. Ainsi, lorsque nous parlons de paiements de coupons, nous parlons en réalité d'opérations de base de données qui ont lieu automatiquement à un moment convenu.

Si cette automatisation est techniquement réalisable, elle souffre d’une difficulté financière. Si les fonds utilisés pour le paiement des coupons sont contrôlés par le contrat intelligent de l'obligation, alors ces paiements peuvent effectivement être garantis. Mais cela signifie aussi que ces fonds ne peut pas être utilisé par l’émetteur de l’obligation à d’autres fins. Et si ces fonds sous le contrôle du contrat intelligent, alors il n'y a aucun moyen de garantir le paiement.

En d’autres termes, une smart bond est soit inutile pour l’émetteur, soit inutile pour l’investisseur. Et si vous y réfléchissez, c’est un résultat tout à fait évident. Du point de vue de l'investisseur, l'intérêt d'une obligation réside dans son taux de rendement attractif, au prix d'un certain risque de défaut. Et pour l'émetteur, le but d'une obligation est de lever des fonds pour une activité productive mais quelque peu risquée, comme la construction d'une nouvelle usine. Il n'est pas possible pour l'émetteur d'obligations d'utiliser les fonds levés tout en garantissant le remboursement de l'investisseur. Il ne faut pas s'étonner que le lien entre risque et rendement n’est pas un problème que les blockchains peuvent résoudre.

Cacher des données confidentielles

Comme j'ai écrit précédemment, le plus grand défi du déploiement des blockchains est la transparence radicale qu’elles offrent. Par exemple, si dix banques créent ensemble une blockchain et que deux d’entre elles effectuent une transaction bilatérale, celle-ci sera immédiatement visible pour les huit autres. Bien qu'il existe diverses stratégies pour atténuer ce problème, aucune ne vaut la simplicité et l'efficacité d'une base de données centralisée, dans laquelle un administrateur de confiance a un contrôle total sur qui peut voir quoi.

Certains pensent que les contrats intelligents peuvent résoudre ce problème. Ils commencent par le fait 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 médiatisées par le code du contrat, ce qui rend impossible pour un contrat de lire directement les données d'un autre. (Ce couplage étroit entre les données et le code est appelé encapsulation et constitue le fondement du populaire programmation orientée objet paradigme.)

Alors, si un contrat intelligent ne peut pas 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 cacher des informations dans un contrat intelligent ? Malheureusement, la réponse est non. Parce que même si un contrat intelligent ne peut pas lire les données d'un autre, ces données sont toujours stockées sur chaque nœud de la chaîne. Pour chaque participant à la blockchain, c'est dans la mémoire ou le disque d'un système que ce participant contrôle entièrement. Et rien ne les empêche de lire les informations de leur propre système, si et quand ils choisissent de le faire.

Cacher des données dans un contrat intelligent est aussi sécurisé que de les cacher dans le code HTML d’une page Web. Bien sûr, les utilisateurs Web habituels ne le verront pas, car il n'est pas affiché dans la fenêtre de leur navigateur. Mais il suffit qu'un navigateur Web ajoute une fonction « Afficher la source » (comme ils l'ont tous fait), et les informations cachées deviennent universellement visibles. 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 à moitié décent pourrait le faire en une heure environ.

À quoi servent les contrats intelligents

Avec tant de choses que les contrats intelligents ne peuvent pas faire, on pourrait se demander à quoi ils servent réellement. Mais pour répondre à cette question, nous devons revenir aux fondamentaux des blockchains elles-mêmes. Pour rappel, une blockchain permet de partager une base de données directement et en toute sécurité entre des entités qui ne se font pas confiance, sans nécessiter un 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 via des « transactions », qui contiennent un ensemble de modifications apportées à cette base de données qui doivent réussir ou échouer dans leur ensemble. 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 quantité du compte d'Alice et (c) ajoute la même quantité au compte de Bob. .

Dans une base de données centralisée classique, ces transactions sont créées par une seule autorité de confiance. En revanche, dans une base de données partagée basée sur une blockchain, les transactions peuvent être créées par n'importe quel utilisateur 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 librement se donner autant d'argent qu'ils le souhaitent.

On peut imaginer différentes manières d’exprimer ces règles, mais pour l’instant il existe deux paradigmes dominants, inspirés respectivement du Bitcoin et de l’Ethereum. La méthode Bitcoin, que nous pourrions appeler « contraintes de transaction », évalue chaque transaction en termes de : (a) les entrées de base de données supprimées par cette transaction, et (b) les entrées créées. Dans un grand livre financier, la règle stipule que la quantité totale de fonds dans les écritures supprimées doit correspondre au total de celles créées. (Nous considérons que la modification d'une entrée existante équivaut à supprimer cette entrée et à en créer une nouvelle à sa place.)

Le deuxième paradigme, issu d’Ethereum, est celui des contrats intelligents. Celui-ci précise 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, nous pouvons considérer cela comme un forcée procédure stockée.) Pour modifier les données d'un contrat, les utilisateurs de la blockchain envoient demandes à son code, qui détermine si et comment répondre à ces demandes. Un péché cet exemple, le contrat intelligent pour 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é de fonds suffisants, déduire d'un compte et ajouter à un autre.

Ces deux paradigmes sont efficaces, et chacun a ses avantages et ses inconvénients, comme je l'ai déjà dit. discuté en profondeur précédemment. Pour résumer, 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é. Alors pour revenir à la question de savoir à quoi servent les smart contracts :

Les contrats intelligents sont destinés aux cas d'utilisation de la blockchain qui ne peuvent pas ê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 soient admissibles. Toutes les applications blockchain convaincantes que je connais peuvent être mises en œuvre avec des transactions de type Bitcoin, qui peuvent gérer les autorisations et le stockage général des données, ainsi que la création, le transfert, le dépôt, l'échange et la destruction d'actifs. Néanmoins, de nouveaux cas d'utilisation continuent d'apparaître, et je ne serais pas surpris si certains do 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 qu’une méthode permettant de restreindre les transactions effectuées dans une base de données. C’est sans aucun doute une chose utile et essentielle pour sécuriser le partage de cette base de données. Mais les contrats intelligents ne peuvent rien faire d’autre, et ils ne peuvent certainement pas échapper aux limites de la base de données dans laquelle ils résident.

Veuillez poster vos commentaires chez LinkedIn.